Date: Fri, 5 Jun 1998 06:42:00 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: lcremean@tidalwave.net Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Stuart Henderson <stuart@internationalschool.co.uk>, Eivind Eklund <eivind@yes.no>, "Justin T. Gibbs" <gibbs@plutotech.com>, stable@FreeBSD.ORG Subject: Re: Matt Behrens: Re: kernel compile problem Message-ID: <l0313030bb19d53ec5ce7@[208.2.87.10]> In-Reply-To: <19980604234005.55226@st-lcremean.tidalwave.net> References: <25782.897013623@time.cdrom.com>; from Jordan K. Hubbard on Thu, Jun 04, 1998 at 07:27:03PM -0700 <3576C83E.41A790F9@internationalschool.co.uk> <25782.897013623@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:40 PM -0500 6/4/98, Lee Cremeans wrote: >The more I look at this problem, the more i think that bundling config in >the /usr/src/sys area instead of /usr/sbin makes more sense. /usr/sbin is a >bad place for it anyway--it's really only meant for use on the kernel, at >least in FreeBSD. It could be like /usr/src/sys/whatever/config... I disagree. It is not a part of the kernel. It is a tool used to generate the kernel. Should we move "gcc", "yacc", "perl", ... into the kernel space just because (if) they are used to build the kernel? I think that the answer is obviously "No". There is a fundamental difference. The kernel sources are compiled in the context of "KERNEL" and statically linked (today, in .aout format, even on otherwise "i386/elf" systems). The config tool is linked using shared libraries, etc. "src/usr.sbin/" IS an appropriate place for it. "src/sys" IS NOT. >PS: Even if people don't like the idea of moving it to /usr/src/sys, >including it in the CVS and CVSup src-sys modules would work, since it would >keep matching versions of config together. IMHO, this is the correct approach. If someone wants to go to the trouble, the sources for config could be added to the kernel source distribution iff config changes after a release. At the time of the next release, they could again be removed. However, I doubt that it is worth the extra effort. I'd simply throw them in all the time. However, if the list of similar tools were to grow, I would reconsider. That brings us back to the question of "Why?". Should the 2.2 branch have been changed now? Perhaps this aspect should have been frozen until we are preparing for a 2.2.7 release. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l0313030bb19d53ec5ce7>
