Re: Two Junior Kernel Hacker tasks..
John Baldwin wrote: Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. Me too. I can make a small set of changes to a couple of kernel files, rebuild, reinstall, and reboot, and be running the new kernel in under 3 minutes. Adding a make depend puts that a bit further out (annoyingly so). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
* Terry Lambert [EMAIL PROTECTED] [010626 02:41] wrote: John Baldwin wrote: Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. Me too. I can make a small set of changes to a couple of kernel files, rebuild, reinstall, and reboot, and be running the new kernel in under 3 minutes. Adding a make depend puts that a bit further out (annoyingly so). You guys are right, you just have to be watchful if new headers are added to files that you don't forget to 'make depend' otherwise it gets nasty real fast like if those headers change. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 24-Jun-01 Peter Pentchev wrote: On Sat, Jun 23, 2001 at 10:44:51PM -0700, John Baldwin wrote: On 23-Jun-01 Peter Pentchev wrote: On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. OK, so if you're really really sure your changes do not affect the dependency graph, use -DNOKERNELDEPEND :) make ; make install is a _lot_ shorter to type than: make -DNOKERNELDEPEND -DDOWHATIWANTDANGIT -DDONTDOTHIS -DDONTDOTHATOTHERTHINGEITHER buildkernel ; make -DDONTINSTALLFOO -DDONTTRYTODOTHIS installkernel And I won't even mention 'make reinstall'... -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
Sat, Jun 23, 2001 at 12:23:35, tlambert2 (Terry Lambert) wrote about Re: Two Junior Kernel Hacker tasks..: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). It is mostly problem of current implementation. You can define some variables (NO_KERNELDEPEND, NOCLEAN, NO_KERNELCONFIG) and avoid it, if you are sure you can do it in this way. I said about the right idea to move last rarity - kernel building - outside from /usr/src, to /usr/obj or another object prefix. The make release process has similar problems, for Of course, and `make buildworld' also. But for most cases -DNOCLEAN is enough to skip unnesessary steps. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 10:50:00AM -0700, Matthew Jacob wrote:
Why can't we do it like NetBSD and have
sys/${MACHINE_ARCH}/compile?
It makes it harder to make src/sys/compile a single simple symlink to
writable storage.
Our /sys layout is suffiently different from NetBSD, I don't think there
is any benefit from following them (nad it would be
sys/arch/${MACHINE_ARCH}/compile anyway).
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 01:51:54PM -0500, Will Andrews wrote: On Fri, Jun 22, 2001 at 11:43:58AM -0700, Matthew Jacob ([EMAIL PROTECTED]) wrote: Yes, and you're right. But we'll probably never do this (tm). Never say never. I for one am in favor of that system. =) Yuck! Puke! I for one am not in favor of that system. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 12:42:36PM -0600, Warner Losh wrote:
Please use ${MACHINE}, not ${MACHINE_ARCH}. That way I can build
GENERIC for both i386 and pc98 at the same time without resorting to
the GENERIC98 hack I use now.
...
I'd be up for doing this, so long as I got to choose where to build
into :-)
sys/arch/${MACHINE}/compile/FOO
but that would start the arch bikeshed. I'd love to just do it.
Which is another good reason for sys/compile/${MACHINE}/FOO
Otherwise where DOES the pc98 kernel builds happen? Under the
non-existant sys/pc98/ ?
With powerpc, we are going to have a lot of different ports ala
i386/pc98 (that have the same MAHINCE_ARCH, but different MACHINE) if
NetBSD is any indication.
Even more data that IMHO makes sys/compile/${MACHINE}/FOO make more
sense.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 12:11:36PM -0700, John Baldwin wrote:
On 22-Jun-01 Warner Losh wrote:
In message [EMAIL PROTECTED] John Baldwin writes:
: 2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than
: sys/compile/FOO.
Please use ${MACHINE}, not ${MACHINE_ARCH}. That way I can build
GENERIC for both i386 and pc98 at the same time without resorting to
the GENERIC98 hack I use now.
Sure, sounds good. Actually, with mjacob's suggestion, I would go with
sys/${MACHINE}/compile/FOO
pc98 and powerpc variations will make this ugly.
I would tackle the sys/arch bikeshed on its own merits for now. (BTW,
I favor sys/arch FWIW). If we use the path I proposed above
(sys/MACHINE/compile/FOO) then if we do a sys/MACHINE -
sys/arch/MACHINE move we get the compile directory move for free.
PUKE, GROSS. NO.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 10:44:51PM -0700, John Baldwin wrote: On 23-Jun-01 Peter Pentchev wrote: On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. OK, so if you're really really sure your changes do not affect the dependency graph, use -DNOKERNELDEPEND :) G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
sys/${MACHINE_ARCH}/compile?
It makes it harder to make src/sys/compile a single simple symlink to
writable storage.
There is no need to make symlink in src tree.
-- David ([EMAIL PROTECTED])
Are you David O'Brien or freebsd-hackers list itself?
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: On Fri, Jun 22, 2001 at 12:42:36PM -0600, Warner Losh wrote:
: Please use ${MACHINE}, not ${MACHINE_ARCH}. That way I can build
: GENERIC for both i386 and pc98 at the same time without resorting to
: the GENERIC98 hack I use now.
: ...
: I'd be up for doing this, so long as I got to choose where to build
: into :-)
:
: sys/arch/${MACHINE}/compile/FOO
:
: but that would start the arch bikeshed. I'd love to just do it.
:
:
: Which is another good reason for sys/compile/${MACHINE}/FOO
: Otherwise where DOES the pc98 kernel builds happen? Under the
: non-existant sys/pc98/ ?
sys/pc98 does exist.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: Sure, sounds good. Actually, with mjacob's suggestion, I would go with
: sys/${MACHINE}/compile/FOO
:
: pc98 and powerpc variations will make this ugly.
No they won't. pc98 is the reason that this *MAKES* sense.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: On Fri, Jun 22, 2001 at 10:50:00AM -0700, Matthew Jacob wrote:
: Why can't we do it like NetBSD and have
:
: sys/${MACHINE_ARCH}/compile?
:
: It makes it harder to make src/sys/compile a single simple symlink to
: writable storage.
Generally, most people will have at most one or two architectures, so
the symlink isn't that hard to do. Also, since most people wanting to
do this could also just specify the command line option to config.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: Which is another good reason for sys/compile/${MACHINE}/FOO
: Otherwise where DOES the pc98 kernel builds happen? Under the
: non-existant sys/pc98/ ?
David, a simple ls to sys/pc98 shows that it is populated with lots of
files.
% ls ~/FreeBSD/src/sys/pc98
CVS apm confi386pc98
So that's not an argument against it.
: With powerpc, we are going to have a lot of different ports ala
: i386/pc98 (that have the same MAHINCE_ARCH, but different MACHINE) if
: NetBSD is any indication.
:
: Even more data that IMHO makes sys/compile/${MACHINE}/FOO make more
: sense.
Actually, I don't think it argues in favor of
sys/compile/${MACHINE}/FOO at all. *ALL* ${MACHINE} ports must have a
sys/${MACHINE} in the current scheme. That's by definition.
I also think that as we get more and more ports for power pc, we'll
see more people that need/want to do cross compiling or having one
tree for multiple ports.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). The make release process has similar problems, for that matter. Too bad no one seems willing to commit incremental fixes towards cleaning that up, or, when they are willing (as in this case), people argue that it's unnecessary, and nothing ever gets done. I think they should go for it with the architecture specific config directories (though I would point out that they can achieve this effect already, with the correct config arguments -- I do agree it should be the default). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). Terry, this is simply not true. Even in -stable, config(8) is smart enough to try reading the opt_*.h files, and not change them if they already contain the values it is about to write there. See for yourself: [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD/opt_*.h | head -2 -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_aac.h -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_wavelan.h [root@ringworld:v1 /usr/src]# As you can see, the two most recent files date back to June 11th... [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD | head -3 total 6187 -rw-r--r-- 1 root wheel 424510 Jun 23 22:51 .depend -rwxr-xr-x 1 root wheel 1963795 Jun 23 14:34 kernel [root@ringworld:v1 /usr/src]# ..the kernel was rebuilt today at 14:34, and the .depend file was regenerated by a 'make -DNOCLEAN buildkernel' about two minutes ago. No opt*.h files were changed, NO recompilation was done, since everything was completely up-to-date. About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
Peter Pentchev wrote: Terry, this is simply not true. Even in -stable, config(8) is smart enough to try reading the opt_*.h files, and not change them if they already contain the values it is about to write there. Rerunning config and make depend always result in more things being recompiled for me, than just me typing make. The buildkernel target also can not handle all of the intricacies of all the parameters that you might want to pass to config: things are lost. It's not a reasonable workaround to the problem under discussion (building multiple kernels for multiple architectures using one tree). Example: All my PPC based NetBSD systems run different kernel configurations, specific to the machine (not processor) architecture. But everything other than the kernel and modules should be shared, since all the systems kernels present the same ABI to user space. Rebuilding everything is not a reasonable option. [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD/opt_*.h | head -2 -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_aac.h -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_wavelan.h [root@ringworld:v1 /usr/src]# As you can see, the two most recent files date back to June 11th... Next time, include the other things like param.c and so on, created by config. I want to avoid _all_ unnecessary rebuilds. (Technically, the vers.c rebuild is unnecessary, too, since nothing is supposed to have changes, so vers.c should not have been rewritten -- but that's another discussion... 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 02:03:53PM -0700, Terry Lambert wrote: Peter Pentchev wrote: Terry, this is simply not true. Even in -stable, config(8) is smart enough to try reading the opt_*.h files, and not change them if they already contain the values it is about to write there. Rerunning config and make depend always result in more things being recompiled for me, than just me typing make. Running 'make buildkernel' results in nothing at all recompiled for me (please read the whole of my message this time). The buildkernel target also can not handle all of the intricacies of all the parameters that you might want to pass to config: things are lost. If it's just parameters you want to pass, then use the CONFIG_ARGS make env variable. It's not a reasonable workaround to the problem under discussion (building multiple kernels for multiple architectures using one tree). For multiple architectures, no, it is not - but that was the whole point of half this thread, wasn't it? Making the kernel build directories arch-specific.. Example: All my PPC based NetBSD systems run different kernel configurations, specific to the machine (not processor) architecture. But everything other than the kernel and modules should be shared, since all the systems kernels present the same ABI to user space. Rebuilding everything is not a reasonable option. So mount your /usr/obj accordingly - NFS mount of the whole, a local fs (or maybe even a nullfs, but I won't go into that) mount of the kernel-specific subdirs. Then, use buildkernel. [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD/opt_*.h | head -2 -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_aac.h -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_wavelan.h [root@ringworld:v1 /usr/src]# As you can see, the two most recent files date back to June 11th... Next time, include the other things like param.c and so on, created by config. I want to avoid _all_ unnecessary rebuilds. Uh.. excuse me? Did you read two lines further, where I pasted an ls of the *same* directory, and the two *most recent* files? Only the .depend file had a modification time two minutes ago, the kernel itself was the next file in the list, and it had a mtime of several hours earlier. Not param.c, not vers.c, nothing had beed changed by the buildkernel target. (Technically, the vers.c rebuild is unnecessary, too, since nothing is supposed to have changes, so vers.c should not have been rewritten -- but that's another discussion... 8-)). Look again. It was not rewritten. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 23-Jun-01 Peter Pentchev wrote: On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, 22 Jun 2001, John Baldwin wrote:
Hey all,
This is a request for some simple changes to the kernel configuration stuff
that would be nice to have if someone wants to do them before I finally (if
ever) get around to doing it. Both have to do with making our kernel config
stuff more multi-platform friendly.
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than sys/compile/FOO.
This is very helpful when you share the same sys/ tree across several
machines with different architectures. For example, I share the same sys/
tree via NFS across almost all my testboxes including alpha and i386. Every
time I want to compile GENERIC (I keep kernel.GENERIC up to date on my boxes)
as part of an installworld I have to go manipulate symlinks (and/or shuffle
directories around). Fixing this would make life for the non-x86 centric
types a bit easier, although there'll probably be a big bikeshed over
changing the build directory. *sigh*
Why can't we do it like NetBSD and have
sys/${MACHINE_ARCH}/compile?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Matthew Jacob wrote:
On Fri, 22 Jun 2001, John Baldwin wrote:
Hey all,
This is a request for some simple changes to the kernel configuration stuff
that would be nice to have if someone wants to do them before I finally (if
ever) get around to doing it. Both have to do with making our kernel config
stuff more multi-platform friendly.
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not
having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than
sys/compile/FOO.
This is very helpful when you share the same sys/ tree across several
machines with different architectures. For example, I share the same
sys/
tree via NFS across almost all my testboxes including alpha and i386.
Every
time I want to compile GENERIC (I keep kernel.GENERIC up to date on my
boxes)
as part of an installworld I have to go manipulate symlinks (and/or
shuffle
directories around). Fixing this would make life for the non-x86 centric
types a bit easier, although there'll probably be a big bikeshed over
changing the build directory. *sigh*
Why can't we do it like NetBSD and have
sys/${MACHINE_ARCH}/compile?
Sure, fine. I don't really care which, I just would like the problem solved
somehow. :)
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
sys/${MACHINE_ARCH}/compile?
Sure, fine. I don't really care which, I just would like the problem solved
somehow. :)
I seem to recall that the 2 or 3 times I've brought this up over the last 3-4
years either Bruce or Peter or both said No!, but my memory could be playing
me false.
What *I* do is NFS mount my test source from a common machine, but then nfs
loopback mount the compile directory for each machine. I'd use a nullfs mount
if that worked.
This has the feature of avoiding the multiplatform foo (mostly- it's been
known to break over the last year or so), and also to get more reasonable
compile performance.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Matthew Jacob wrote:
sys/${MACHINE_ARCH}/compile?
Sure, fine. I don't really care which, I just would like the problem solved
somehow. :)
I seem to recall that the 2 or 3 times I've brought this up over the last 3-4
years either Bruce or Peter or both said No!, but my memory could be playing
me false.
What *I* do is NFS mount my test source from a common machine, but then nfs
loopback mount the compile directory for each machine. I'd use a nullfs mount
if that worked.
This has the feature of avoiding the multiplatform foo (mostly- it's been
known to break over the last year or so), and also to get more reasonable
compile performance.
The thing I like though is that when my test box hangs, I have the kernel.debug
still accessible so I can pull up remote gdb on the machine. Hence the desire
to share sys/compile over NFS as well.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
The thing I like though is that when my test box hangs, I have the kernel.debug still accessible so I can pull up remote gdb on the machine. Hence the desire to share sys/compile over NFS as well. Yes, that's helpful too. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] John Baldwin writes:
: 2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than sys/compile/FOO.
Please use ${MACHINE}, not ${MACHINE_ARCH}. That way I can build
GENERIC for both i386 and pc98 at the same time without resorting to
the GENERIC98 hack I use now.
:This is very helpful when you share the same sys/ tree across several
:machines with different architectures. For example, I share the same sys/
:tree via NFS across almost all my testboxes including alpha and i386. Every
:time I want to compile GENERIC (I keep kernel.GENERIC up to date on my boxes)
:as part of an installworld I have to go manipulate symlinks (and/or shuffle
:directories around). Fixing this would make life for the non-x86 centric
:types a bit easier, although there'll probably be a big bikeshed over
:changing the build directory. *sigh*
:
I'd be up for doing this, so long as I got to choose where to build
into :-)
sys/arch/${MACHINE}/compile/FOO
but that would start the arch bikeshed. I'd love to just do it.
With powerpc, we are going to have a lot of different ports ala
i386/pc98 (that have the same MAHINCE_ARCH, but different MACHINE) if
NetBSD is any indication.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 10:50:00AM -0700, Matthew Jacob ([EMAIL PROTECTED]) wrote:
Why can't we do it like NetBSD and have
sys/${MACHINE_ARCH}/compile?
I thought it was sys/arch/${MACHINE_ARCH}/compile? ;)
Aren't you a NetBSD developer[*]?
--
wca
[*] Sorry, couldn't resist.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] Matthew Jacob writes:
: Why can't we do it like NetBSD and have
:
: sys/${MACHINE_ARCH}/compile?
That would be my second chopice (assumnig that we really do do it like
NetBSD and use ${MACHINE} rather than ${MACHINE_ARCH}).
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, 22 Jun 2001, Will Andrews wrote:
On Fri, Jun 22, 2001 at 10:50:00AM -0700, Matthew Jacob ([EMAIL PROTECTED]) wrote:
Why can't we do it like NetBSD and have
sys/${MACHINE_ARCH}/compile?
I thought it was sys/arch/${MACHINE_ARCH}/compile? ;)
Aren't you a NetBSD developer[*]?
--
wca
[*] Sorry, couldn't resist.
Yes, and you're right. But we'll probably never do this (tm).
Groan...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] Will Andrews writes:
: I thought it was sys/arch/${MACHINE_ARCH}/compile? ;)
: Aren't you a NetBSD developer[*]?
Actually, it is sys/arch/${MACHINE}/compile since you can have
different machines based on the same machine_arch. Look at the number
of mips, 60k, powerpc and arm ports.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] Matthew Jacob writes:
: Yes, and you're right. But we'll probably never do this (tm).
I keep trying :-)
However, I think the following would work for
sys/${MACHINE}/compile/FOO. Note, I only did i386, but could do
others as well fairly quickly.
Warner
Index: sys/conf/Makefile.i386
===
RCS file: /home/imp/FreeBSD/CVS/src/sys/conf/Makefile.i386,v
retrieving revision 1.236
diff -u -r1.236 Makefile.i386
--- sys/conf/Makefile.i386 2001/06/13 10:58:28 1.236
+++ sys/conf/Makefile.i386 2001/06/22 18:47:09
@@ -29,7 +29,7 @@
.if exists(./@/.)
S= ./@
.else
-S= ../..
+S= ../../..
.endif
.endif
M= ${MACHINE_ARCH}
Index: usr.sbin/config/config.8
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/config/config.8,v
retrieving revision 1.26
diff -u -r1.26 config.8
--- usr.sbin/config/config.82001/01/22 07:03:06 1.26
+++ usr.sbin/config/config.82001/06/22 18:46:38
@@ -110,7 +110,7 @@
.Fx .
.Nm
creates the directory
-.Pa ../../compile/SYSTEM_NAME
+.Pa ../compile/SYSTEM_NAME
or the one given with the
.Fl d
option
Index: usr.sbin/config/main.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/config/main.c,v
retrieving revision 1.50
diff -u -r1.50 main.c
--- usr.sbin/config/main.c 2001/02/23 00:22:04 1.50
+++ usr.sbin/config/main.c 2001/06/22 18:46:28
@@ -67,7 +67,7 @@
#define FALSE (0)
#endif
-#defineCDIR../../compile/
+#defineCDIR../compile/
char * PREFIX;
char destdir[MAXPATHLEN];
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Fri, Jun 22, 2001 at 11:43:58AM -0700, Matthew Jacob ([EMAIL PROTECTED]) wrote:
Yes, and you're right. But we'll probably never do this (tm).
Never say never. I for one am in favor of that system. =)
Unfortunately at the moment we have sys/${MACHINE}/compile rather
than sys/arch/${MACHINE}/compile so we'd need repocopies (and a
lot of them I would imagine).
--
wca
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] Warner Losh writes:
: However, I think the following would work for
: sys/${MACHINE}/compile/FOO. Note, I only did i386, but could do
: others as well fairly quickly.
Actually, the last patch is bad. Try this one. You will need to
mkdir sys/${MACHINE}/compile. This at least makes it through make
depend.
Warner
Index: sys/conf/Makefile.i386
===
RCS file: /home/imp/FreeBSD/CVS/src/sys/conf/Makefile.i386,v
retrieving revision 1.236
diff -u -r1.236 Makefile.i386
--- sys/conf/Makefile.i386 2001/06/13 10:58:28 1.236
+++ sys/conf/Makefile.i386 2001/06/22 18:47:09
@@ -29,7 +29,7 @@
.if exists(./@/.)
S= ./@
.else
-S= ../..
+S= ../../..
.endif
.endif
M= ${MACHINE_ARCH}
Index: usr.sbin/config/config.8
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/config/config.8,v
retrieving revision 1.26
diff -u -r1.26 config.8
--- usr.sbin/config/config.82001/01/22 07:03:06 1.26
+++ usr.sbin/config/config.82001/06/22 18:46:38
@@ -110,7 +110,7 @@
.Fx .
.Nm
creates the directory
-.Pa ../../compile/SYSTEM_NAME
+.Pa ../compile/SYSTEM_NAME
or the one given with the
.Fl d
option
Index: usr.sbin/config/main.c
===
RCS file: /home/imp/FreeBSD/CVS/src/usr.sbin/config/main.c,v
retrieving revision 1.50
diff -u -r1.50 main.c
--- usr.sbin/config/main.c 2001/02/23 00:22:04 1.50
+++ usr.sbin/config/main.c 2001/06/22 18:52:03
@@ -67,7 +67,7 @@
#define FALSE (0)
#endif
-#defineCDIR../../compile/
+#defineCDIR../compile/
char * PREFIX;
char destdir[MAXPATHLEN];
@@ -158,8 +158,7 @@
{
char xxx[MAXPATHLEN];
if (*srcdir == '\0')
- (void)snprintf(xxx, sizeof(xxx), ../../%s/include,
- machinename);
+ (void)snprintf(xxx, sizeof(xxx), ../../include);
else
(void)snprintf(xxx, sizeof(xxx), %s/%s/include,
srcdir, machinename);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Warner Losh wrote:
In message [EMAIL PROTECTED] John Baldwin writes:
: 2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than
: sys/compile/FOO.
Please use ${MACHINE}, not ${MACHINE_ARCH}. That way I can build
GENERIC for both i386 and pc98 at the same time without resorting to
the GENERIC98 hack I use now.
Sure, sounds good. Actually, with mjacob's suggestion, I would go with
sys/${MACHINE}/compile/FOO
:This is very helpful when you share the same sys/ tree across several
:machines with different architectures. For example, I share the same
:sys/
:tree via NFS across almost all my testboxes including alpha and i386.
:Every
:time I want to compile GENERIC (I keep kernel.GENERIC up to date on my
:boxes)
:as part of an installworld I have to go manipulate symlinks (and/or
:shuffle
:directories around). Fixing this would make life for the non-x86 centric
:types a bit easier, although there'll probably be a big bikeshed over
:changing the build directory. *sigh*
:
I'd be up for doing this, so long as I got to choose where to build
into :-)
sys/arch/${MACHINE}/compile/FOO
but that would start the arch bikeshed. I'd love to just do it.
I would tackle the sys/arch bikeshed on its own merits for now. (BTW, I favor
sys/arch FWIW). If we use the path I proposed above (sys/MACHINE/compile/FOO)
then if we do a sys/MACHINE - sys/arch/MACHINE move we get the compile
directory move for free.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] John Baldwin writes:
: Sure, sounds good. Actually, with mjacob's suggestion, I would go with
: sys/${MACHINE}/compile/FOO
You are behind on your email. I've already posted patches that do
exactly this. It turns out to be very easy. I've also built a kernel
with them. I'm also getting ready to build a pc98 kernel too.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Warner Losh wrote:
In message [EMAIL PROTECTED] John Baldwin writes:
: Sure, sounds good. Actually, with mjacob's suggestion, I would go with
: sys/${MACHINE}/compile/FOO
You are behind on your email. I've already posted patches that do
exactly this. It turns out to be very easy. I've also built a kernel
with them. I'm also getting ready to build a pc98 kernel too.
I think we are just getting e-mails crossed. :) Sounds good. Can't wait to
see the commit. :) Now to get someone to tackle the first item on the list...
Warner
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] John Baldwin writes: : I think we are just getting e-mails crossed. :) Sounds good. Can't wait to : see the commit. :) Now to get someone to tackle the first item on the list... Hey, I did my part for the cause. Let someone else do NOTES. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
John Baldwin [EMAIL PROTECTED] writes:
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
OpenBSD (and I think NetBSD) solve this problem by having an 'include'
directive in the kernel config file. E.g., in
sys/arch/i386/conf/GENRIC (the MD config file):
machine i386
...
include ../../../conf/GENREIC # -- MI config file
...
I think this is much more general than just splitting NOTES. Is there
any reason we shouldn't do this? I'd be willing to implement
'include' in config(8).
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Dima Dorfman wrote:
John Baldwin [EMAIL PROTECTED] writes:
1) Split sys/i386/conf/NOTES up into MI and MD parts. The MI portion would
become sys/conf/NOTES and would contain all the machine independent
options and devices. The MD options and devices would live in
sys/${MACHINE_ARCH}/conf/NOTES. This would include altering the
sys/${MACHINE_ARCH}/conf/Makefile's (based on the LINT: target in the
i386 Makefile) to concatenate the MI and MD NOTES files together to
feed to makelint.pl to build LINT. This addresses problems with not
having
a place for non-i386 kernel options/devices that aren't in GENERIC for
example.
OpenBSD (and I think NetBSD) solve this problem by having an 'include'
directive in the kernel config file. E.g., in
sys/arch/i386/conf/GENRIC (the MD config file):
machine i386
...
include ../../../conf/GENREIC # -- MI config file
...
I think this is much more general than just splitting NOTES. Is there
any reason we shouldn't do this? I'd be willing to implement
'include' in config(8).
That's fine. LINT is still special, because we do extra processing to convert
NOTES to LINT, but that would make updating GENERIC easier.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
Matthew Jacob wrote:
sys/${MACHINE_ARCH}/compile?
Sure, fine. I don't really care which, I just would like the problem solve
d
somehow. :)
I seem to recall that the 2 or 3 times I've brought this up over the last 3-4
years either Bruce or Peter or both said No!, but my memory could be playing
me false.
If I've said that before (and I'm not sure that I have), I have changed my
mind. I would prefer sys/{arch}/compile.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
I seem to recall that the 2 or 3 times I've brought this up over the last 3-4
years either Bruce or Peter or both said No!, but my memory could be playing
me false.
If I've said that before (and I'm not sure that I have), I have changed my
mind. I would prefer sys/{arch}/compile.
*AND THE CROWD CHEERS WILDLY!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
In message [EMAIL PROTECTED] Matthew Jacob writes:
: I seem to recall that the 2 or 3 times I've brought this up over the last 3-4
: years either Bruce or Peter or both said No!, but my memory could be playing
: me false.
:
: If I've said that before (and I'm not sure that I have), I have changed my
: mind. I would prefer sys/{arch}/compile.
:
:
: *AND THE CROWD CHEERS WILDLY!
Maybe I should just commit it :-)
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On 22-Jun-01 Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew Jacob
writes:
: I seem to recall that the 2 or 3 times I've brought this up over the
: last 3-4
: years either Bruce or Peter or both said No!, but my memory could be
: playing
: me false.
:
: If I've said that before (and I'm not sure that I have), I have changed my
: mind. I would prefer sys/{arch}/compile.
:
:
: *AND THE CROWD CHEERS WILDLY!
Maybe I should just commit it :-)
No objection here. :)
Warner
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
Fri, Jun 22, 2001 at 10:52:01, jhb (John Baldwin) wrote about Two Junior Kernel
Hacker tasks..:
2) Build kernels in sys/compile/${MACHINE_ARCH}/FOO rather than sys/compile/FOO.
I'd like to qualify the whole idea to put compilation data in some subdirectory
of /usr/src as harmful. `make buildkernel' places it in more reasoned
place (but /usr/obj/usr/src/sys/compile/i386/zzz is IMHO preferrable than
current /usr/obj/usr/src/sys/zzz). Building in /usr/src/sys/compile is
legacy issue which should be IMO removed, and /usr/sbin/config should require
explicit way in its command line.
But this is bound with another /usr/src pollutions. E.g. one cannot place
kernel config in /etc and say config /etc/kernel.config/nn12 without
moving it and current directory to /usr/src/sys/i386/conf or placing
symlink in it. LINT is also made in /usr/src/sys/${arch}/conf, not /etc
or subdirectory of /etc.
This is very helpful when you share the same sys/ tree across several
machines with different architectures. For example, I share the same sys/
tree via NFS across almost all my testboxes including alpha and i386. Every
time I want to compile GENERIC (I keep kernel.GENERIC up to date on my boxes)
as part of an installworld I have to go manipulate symlinks (and/or shuffle
directories around). Fixing this would make life for the non-x86 centric
types a bit easier, although there'll probably be a big bikeshed over
changing the build directory. *sigh*
make buildkernel is rather easy way to work it around: in any case object
tree is machine-dependent, and one yet another directory does not destroy
anything. ;|
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
