Skip site navigation (1)Skip section navigation (2)
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>