Re: How to recompile kernel after minor changes?
Sat, Jun 02, 2001 at 08:24:54, gzjyliu (Jiangyi Liu) wrote about How to recompile
kernel after minor changes?:
After just changing a little in sys/kern/kern_sig.c, how can I rebuild
the kernel fast? I think it should not take such a long time as 'make
buildkernel' does. Anyway, just kern_sig.c need to be recompiled and
the kernel can be linked. So how do you guys do in such case?
With changing only sys/kern/kern_sig.c,
`make -DNOCLEAN -DNO_KERNELDEPEND -DNO_KERNELCONFIG -DNO_MODULES' can be used.
But,
cd /usr/obj/usr/src/sys/${KERNCONF}
make -DNO_MODULES
will be better and faster for human due to shorter commands.
Really, `make buildkernel' is nesessary only for cross-platform build
(`make buildworld' on earlier system is strictly considered as
cross-platform build), and is too expensive for already installed system.
But this receipt should be used with caution. Changes in conf/files*, e.g.,
require reconfiguring. Changes in headers require `make depend'.
Some changes in file bodies also require `make depend', such as for aic7xxx
stuff. If you don't know exactly which remakings are required by your
change, do full reconfiguring and remaking.
For modules, you should note that they aren't built with specified
kernel config. If you strictly understand when kernel code is changed,
MODULES_WITH_WORLD should be placed constantly in /etc/make.conf. ;-|
For -current, `make install' in kernel compile directory will
move all directory with old kernel and modules. I consider this feature
too annoying, it should be off when either MODULES_WITH_WORLD or NO_MODULES
is set (yes, I consider current feature as brain bug;)))
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: How to recompile kernel after minor changes?
On Sun, Jun 03, 2001 at 10:18:49AM +0300, Valentin Nechayev wrote:
After just changing a little in sys/kern/kern_sig.c, how can I rebuild
the kernel fast? I think it should not take such a long time as 'make
buildkernel' does. Anyway, just kern_sig.c need to be recompiled and
the kernel can be linked. So how do you guys do in such case?
With changing only sys/kern/kern_sig.c,
`make -DNOCLEAN -DNO_KERNELDEPEND -DNO_KERNELCONFIG -DNO_MODULES' can be used.
But,
cd /usr/obj/usr/src/sys/${KERNCONF}
make -DNO_MODULES
or ``make kernel''
and if you want to live dangerously ``make kernel-reinstall''.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Real technical comparison
In article [EMAIL PROTECTED] you wrote: Thank you for not telling it to one of my servers which is running around with about 10 concurrent connections biting its tail. I wouldn't like to hurt its feelings. And I've got the feeling that it will have to bear a bit more of that beating. Interesting, what's that thing doing ? Grabing stuff from a number of database servers, combining it, turning it into HTML-documents (including converting graphics formats) and handing them off to the web servers which requested it. Which is causing a nice mix of network load and computations. And no, the server isn't even the highest possible end, not even near it; even my desktop machine has more CPU than this server (I'm just jelous of its RAM size). Noses. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to recompile kernel after minor changes?
Sun, Jun 03, 2001 at 02:02:20, freebsd-hackers (David O'Brien - Hackers) wrote about
Re: How to recompile kernel after minor changes?:
cd /usr/obj/usr/src/sys/${KERNCONF}
make -DNO_MODULES
or ``make kernel''
and if you want to live dangerously ``make kernel-reinstall''.
You are right, it is dangerous because it does not copy current kernel
to /boot/kernel/kernel.old. I need to do it by hands (install -c -fschg ...)
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Garance A Drosihn wrote: | At 9:12 PM -0700 6/1/01, Dima Dorfman wrote: | Honestly, I don't care about this all that much. I'll | let you and David debate this to your liking. If no | consensus develops in the next few days, I'll just | commit what I have now. | | For whatever it's worth, it seems more reasonable to me | to use '--' instead of '=='. Since '--' has NO equals | sign in it, it clearly can't be the setting of an | environment variable. If we're voting on this, I'm very strongly in favour of `--'. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
building /usr/ports/x11-fm/fsv
After a fresh cvsup of prts to my 4.3-STABLE system, I get the following
error when building fsv:
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char glBegin();
int main() {
glBegin()
; return 0; }
configure:4157: checking for glBegin in -lGL
configure:4176: cc -o conftest -O -pipe -I/usr/local/include conftest.c
-lGL -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk12 -lgdk12 -L/usr/local/lib
-Wl,-E -lgmodule12 -lglib12 -lintl -lxpg4 -lXext -lX11 -lm
-L/usr/X11R6/lib/lib -L/usr/local/lib 15
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_getspecific'
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_key_create'
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_setspecific'
configure: failed program was:
#line 4165 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char glBegin();
int main() {
glBegin()
; return 0; }
(end of config.log)
*** Error code 1
Any ideas?
Thanks,
Scott
---begin-encrypted-message---
!SKCUS TN SWODNIW
---end---encrypted-message---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: building /usr/ports/x11-fm/fsv
On ¤é, 6 03, 2001 at 11:28:54 -0400, Scott Nolde wrote: After a fresh cvsup of prts to my 4.3-STABLE system, I get the following error when building fsv: [deleted] configure:4157: checking for glBegin in -lGL configure:4176: cc -o conftest -O -pipe -I/usr/local/include conftest.c -lGL -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk12 -lgdk12 -L/usr/local/lib -Wl,-E -lgmodule12 -lglib12 -lintl -lxpg4 -lXext -lX11 -lm -L/usr/X11R6/lib/lib -L/usr/local/lib 15 /usr/X11R6/lib/libGL.so: undefined reference to `pthread_getspecific' /usr/X11R6/lib/libGL.so: undefined reference to `pthread_key_create' /usr/X11R6/lib/libGL.so: undefined reference to `pthread_setspecific' this was reported as pr/27036 -- Testing can show the presence of bugs, but not their absence. --- Edsger W. Dijkstra PGP signature
Re: UFS large directory performance
In message [EMAIL PROTECTED], Matt Dillon writes: I would further recommend a (dynamic) array of pointers at the first level as part of the summary structure. Any given array entry would either point to the second level array (the 512 byte allocations), be NULL (no second level array was necessary), or be (void *)-1 which would indicate that the second level array was reclaimed for other uses. Nice idea, but I'm not sure I see the benefit of partially reclaiming second-level arrays. Because it is a hash array, there isn't really the concept of a working set; a directory that is `in use' will rarely see many create/rename/delete operations on a small fixed set of filenames. The lookup case is already cached elsewhere. I think an all-or-nothing approach is likely to perform better and be simpler to implement. Even the lazy allocation of second-level arrays is unlikely to help a lot if the hash function does its job well. If the zone allocator is used for the second level block allocations it shouldn't be a problem. You can (had better be able to!) put a mutex around zone frees in -current. The locking issues I could see were more in the area of finding inodes to free hashes from. A linked list of dirhash structures could be maintained (protected by a mutex), but to free the dirhash belonging to an inode, the inode would probably need to be locked. That means dereferencing dirhash-dh_inode-i_vnode and trying to lock it, so things become complex. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS large directory performance
:Nice idea, but I'm not sure I see the benefit of partially reclaiming :second-level arrays. Because it is a hash array, there isn't really :the concept of a working set; a directory that is `in use' will :rarely see many create/rename/delete operations on a small fixed :set of filenames. The lookup case is already cached elsewhere. I :think an all-or-nothing approach is likely to perform better and :be simpler to implement. Even the lazy allocation of second-level :arrays is unlikely to help a lot if the hash function does its job :well. Well, amoung other things it solves the locking problem you bring up below. Even if partial reclamation doesn't maintain performance, it still definitely allows you to reclaim second level entities on the fly from other inodes for use in a new directory scan when you hit up against the memory limit. You could in fact make the reclamation a simple FIFO rather then an LRU, simplifying the structure. :If the zone allocator is used for the second level block allocations :it shouldn't be a problem. You can (had better be able to!) put a mutex :around zone frees in -current. : :The locking issues I could see were more in the area of finding :inodes to free hashes from. A linked list of dirhash structures :could be maintained (protected by a mutex), but to free the dirhash :belonging to an inode, the inode would probably need to be locked. :That means dereferencing dirhash-dh_inode-i_vnode and trying to :lock it, so things become complex. : :Ian I think you can avoid locking the inode. The dirhash is entirely independant of the inode except when it is accessed to aid in a directory operation. The access point can be locked separately with a mutex in -current, and need not be locked at all in -stable. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ptrace()
You might also consider to get this article from http://www.ddj.com/: Dr. Dobb's Journal March 1998 - Benchmarking and Software Testing, Tracing BSD System Calls, by Sean Eric Fagan AFAIR, in this article is explained what steps were necessary to make a ptrace() for FreeBSD. Maybe, someone here knows where to get this article without buying it from ddj. Best Regards, Sven C. Koehler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ptrace()
You might also consider to get this article from http://www.ddj.com/: Dr. Dobb's Journal March 1998 - Benchmarking and Software Testing, Tracing BSD System Calls, by Sean Eric Fagan AFAIR, in this article is explained what steps were necessary to make a ptrace() for FreeBSD. No, this describes the implementation of truss(1) for FreeBSD. You can just go read the sources... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Mon, Jun 04, 2001 at 12:49:43AM +1000, Greg Black wrote: | For whatever it's worth, it seems more reasonable to me | to use '--' instead of '=='. Since '--' has NO equals | sign in it, it clearly can't be the setting of an | environment variable. If we're voting on this, I'm very strongly in favour of `--'. Why? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Mark you've given the justification and logic behind `==' much, much better than I did. Thanks! :-) -- -- David ([EMAIL PROTECTED]) P.S. typically I don't quote a whole message like this, but I think it is important that at least read this one and honestly consider it. On Sat, Jun 02, 2001 at 05:18:45PM +0100, Mark Valentine wrote: people use -- to end subsequences of arguments all the time. No, they use ``--'' to indicate to getopt(3) the end of the _options_ and the _start_ of the arguments. Since env(1) uses getopt(3), ``--'' already has meaning to env(1); it allows environment variables and commands which start with ``-'' (the former is obviously invalid). $ env -i -- -t args currently allows execution of command ``-t''. However, what Dima proposes doesn't seem to be harmful, just slightly confusing, and less surprising than inventing a new delimieter such as ``==''. $ env -i -- foo=bar -- 4=4 args has two distinct uses of `--'' as per Dima's proposal, the first tells getopt(3) to stop processing options, and the second tells the argument processing code to stop looking for variable assignments (i.e. ``4=4'' is a command). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: building /usr/ports/x11-fm/fsv
On Sun, Jun 03, 2001 at 11:28:54AM -0400, Scott Nolde wrote:
After a fresh cvsup of prts to my 4.3-STABLE system, I get the following
error when building fsv:
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char glBegin();
int main() {
glBegin()
; return 0; }
configure:4157: checking for glBegin in -lGL
configure:4176: cc -o conftest -O -pipe -I/usr/local/include conftest.c
-lGL -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk12 -lgdk12 -L/usr/local/lib
-Wl,-E -lgmodule12 -lglib12 -lintl -lxpg4 -lXext -lX11 -lm
-L/usr/X11R6/lib/lib -L/usr/local/lib 15
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_getspecific'
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_key_create'
/usr/X11R6/lib/libGL.so: undefined reference to `pthread_setspecific'
configure: failed program was:
#line 4165 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char glBegin();
int main() {
glBegin()
; return 0; }
(end of config.log)
*** Error code 1
I got the same thing a few days ago trying to build net/fidelio:
/tmp/ccUBd9xD.o: In function `main':
/tmp/ccUBd9xD.o(.text+0x7): undefined reference to `xmlCleanURI'
configure: failed program was:
#line 5000 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char xmlCleanURI();
int main() {
xmlCleanURI()
; return 0; }
(end of config.log)
*** Error code 1
...I'm assuming it's more or less the same thing. I'd be interested in
answers...
--
-Munish
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], David O'Brien writes: Mark you've given the justification and logic behind `==' much, much better than I did. Thanks! :-) And yet, he says: However, what Dima proposes doesn't seem to be harmful, just slightly confusing, and less surprising than inventing a new delimieter such as ``==''. == is very confusing, and it's not the way anything else has ever done delimiters. -- already means change the way you process words. It's only marginally surprising to use it for another change. $ env -i -- foo=bar -- 4=4 args has two distinct uses of `--'' as per Dima's proposal, the first tells getopt(3) to stop processing options, and the second tells the argument processing code to stop looking for variable assignments (i.e. ``4=4'' is a command). And this is fairly consistent. e.g., I used to have a utility which used '--' to indicate each *set* of options, so you could have many of them, as each set of options went to a different program. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
David O'Brien wrote: | On Mon, Jun 04, 2001 at 12:49:43AM +1000, Greg Black wrote: | | For whatever it's worth, it seems more reasonable to me | | to use '--' instead of '=='. Since '--' has NO equals | | sign in it, it clearly can't be the setting of an | | environment variable. | | If we're voting on this, I'm very strongly in favour of `--'. | | Why? The reasons have already been articulated. In brief, there is prior experience with using `--' as an indicator that argument processing is to change at this point; using it twice for the same purpose conflicts less with POLA than inventing the `==' thing, which has never been used for anything. The real reason for my post was that there was an indication that responses in favour of one or the other of the proposed mechanisms would be taken into account in the decision. I don't want to see this `==' idea get up. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
From: [EMAIL PROTECTED] (Peter Seebach) Date: Sun 3 Jun, 2001 Subject: Re: Fixing documented bug in env(1) However, what Dima proposes doesn't seem to be harmful, just slightly confusing, and less surprising than inventing a new delimieter such as ``==''. == is very confusing, and it's not the way anything else has ever done delimiters. -- already means change the way you process words. It's only marginally surprising to use it for another change. Yes, I was (sort of) supporting ``--'' as an end of assignment delimiter here; however, one more compatibility issue throws a spanner in the works... Both ``--'' and ``=='' are valid commands, and currently only the former is handled by env(1): $ env foo=bar -- args executes the command ``--''. Dima's proposal would require this to change: $ env foo=bar -- -- args David's proposal would not break this, and would allow $ env foo=bar == == args to execute the command ``==''. David's proposal only seems to break even more obscure (erroneous?) stuff like: $ env foo=bar == bar=foo command args (Tell me that no script anywhere relies on this long-standing behaviour!) Actually I don't like either solution much (if the documented bug were this easy to fix, it would have been fixed decades ago...). Commands starting with ``-'' already cause grief (e.g. in make(1)), and commands with ``='' in their names almost certainly break in all sorts of other contexts (e.g. when used unquoted in a Bourne shell). (Do any shells still treat ``foo=bar'' as an assigment anywhere on the command line?) I'd leave the bug alone, pending real enlightenment... By the way, who uses env(1) anyway? In the past twenty years, I've only ever used it as shorthand for printenv(1). What's this csh(1) thing? :-) Hmm, would a new csh(1) builtin help any? /bin/sh: $ foo=bar bar=foo echo hello hello $ foo=bar 'bar=foo' echo hello bar=foo: not found /bin/csh: % env foo=bar bar=foo echo hello hello % env foo=bar 'bar=foo' echo hello hello % withenv foo=bar 'bar=foo' echo hello # new withenv(1) builtin bar=foo: not found (I'm not up on csh(1)'s foibles sufficiently to tell whether this would be a done thing, but its syntax already seems fairly, erm, what's the polite word?) Cheers, Mark. -- Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses We're kind of stupid that way. *munch* *munch*and endorses FreeBSD -- http://www.calvinandhobbes.com http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
In message [EMAIL PROTECTED], Mark Valentine w rites: Yes, I was (sort of) supporting ``--'' as an end of assignment delimiter here; however, one more compatibility issue throws a spanner in the works... Both ``--'' and ``=='' are valid commands, and currently only the former is handled by env(1): I doubt that anyone's using either, but it's a good point. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sun, Jun 03, 2001 at 06:56:51PM -0500, Peter Seebach wrote: I doubt that anyone's using either, but it's a good point. '==' was/is part of the Bourne shell command line history stuff (*) a few people at UofSydney hacked together in the very early '80s, But you're right, very few people, if any, use it. -- Andy Newman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Mon, Jun 04, 2001 at 12:52:57AM +0100, Mark Valentine wrote: I'd leave the bug alone, pending real enlightenment... Me too. I've never met a command name with an = in it. By the way, who uses env(1) anyway? In the past twenty years, I've only ever used it as shorthand for printenv(1). What's this csh(1) thing? :-) How else do you throw away your environment, to make sure that daemons that you start with sudo don't do anything silly? I'm pretty sure that I copied this /etc/start_if.ed0 from somewhere, rather than making it up: env - PATH=$PATH dhclient ed0 It's also quite commonly used in /usr/local/etc/rc.d scripts, including qmail and courier-imap. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
From: Andrew Reilly [EMAIL PROTECTED]
Date: Mon 4 Jun, 2001
Subject: Re: Fixing documented bug in env(1)
By the way, who uses env(1) anyway? In the past twenty years, I've only
ever used it as shorthand for printenv(1). What's this csh(1) thing? :-)
How else do you throw away your environment, to make sure that
daemons that you start with sudo don't do anything silly?
env - PATH=$PATH dhclient ed0
Using env(1) without any assumtion about command line assignment parsing
purely as an illustration:
$ env - sh -c PATH=$PATH dhclient ed0
I'd probably wrap thus up in a script (or external program for ease of
use by various shells) - the semantics are subtly different from env(1):
$ clearenv() { env - sh -c $*; } # cheap and nasty to illustrate
$ clearenv PATH=$PATH dhclient ed0
Making clearenv(1) an external program (which doesn't itself parse command
line variable assignments) may simplify quoting, and if ``dhclient'' were
instead a shell builtin such as echo(1), you'd need to avoid the shortcut
above, as in:
$ clearenv PATH=$PATH; export PATH; dhclient ed0
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk
Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses
We're kind of stupid that way. *munch* *munch*and endorses FreeBSD
-- http://www.calvinandhobbes.com http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
$ clearenv() { env - sh -c $*; }# cheap and nasty to illustrate
Hmm, my point was as clear as mud there. I was trying to show that env -
performs a useful function, but a program which performs this function has
no need to duplicate the shell's ability to _assign_ environment variables.
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs [EMAIL PROTECTED] http://www.thuvia.co.uk
Tigers will do ANYTHING for a tuna fish sandwich. Mark Valentine uses
We're kind of stupid that way. *munch* *munch*and endorses FreeBSD
-- http://www.calvinandhobbes.com http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
Andrew Reilly [EMAIL PROTECTED] types: On Mon, Jun 04, 2001 at 12:52:57AM +0100, Mark Valentine wrote: By the way, who uses env(1) anyway? In the past twenty years, I've only ever used it as shorthand for printenv(1). What's this csh(1) thing? :-) How else do you throw away your environment, to make sure that daemons that you start with sudo don't do anything silly? I think it's more commonly used in scripts, so you don't have to worry about where the interpreter is installed. The python folks are recommending the user of #!/usr/bin/env python instead of #!/usr/local/bin/python for scripts, since the former works no matter where python is installed. I understand that some of the perl installation scripts use the same trick. Even cooler - at least as far as I'm concerned - is that you can do this if your interpreter is a script. That is, where #!/usr/local/bin/foobar won't work because foobar is a Perl script, #!/usr/bin/env foobar will work just fine. This is documented on the env man page, though I don't think it's been MFC'ed yet. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
