Date: Mon, 1 Jun 1998 06:31:33 -0500 (CDT) From: Richard Wackerbarth <rkw@dataplex.net> To: Eivind Eklund <eivind@yes.no> Cc: current@FreeBSD.ORG Subject: Re: How about /usr/ports/kernel ? Message-ID: <l03130303b197eeb76060@[208.2.87.10]> In-Reply-To: <19980531235232.04296@follo.net> References: <l03130310b196ef2053d9@[208.2.87.10]>; from Richard Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500 <l03130309b195d4c6fd5b@[208.2.87.10]>; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <l03130309b195d4c6fd5b@[208.2.87.10]> <19980531052120.41610@follo.net> <l03130310b196ef2053d9@[208.2.87.10]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:52 PM -0000 5/31/98, Eivind Eklund wrote:
>However, to be able to do automated kernel builds we have to have a
>way of specifying which kernels to build which do not come as a shock
>to our userbase (this is a political necessity; I don't think either
>of us would get any way arguing otherwise). This probably mean that
>we'll have to support the use of config(8) in the way it is presently
>used for a transition period of at least a year.
Not necessarily. Consider the following strategy:
(1) Replace "config" with a shell script that
(a) copies the configuration file to .../src/sys/compile hierarchy
(b) issues a message reminding the user that the procedure for
building a kernel has been slightly modified, and perhaps
(c) does a "make" in the newly constructed target area.
(2) (To avoid confusion) Rename the present "config" and modify
it to be a tool for the new structure. It would fit in, in a
manner similar to yacc, to be called where needed.
The only transition capability that I see necessary is that we still
handle the present configuration files. If a user wishes to utilize
the expanded capabilities that you (we) would like to be present,
he can also convert to the modified structure for his configuration
description and bypass the old config.
As far as "automatic kernel build" is concerned, I think that this can
be handled by having an optional Makefile.inc in the src/sys structure
that adds SUBDIR's for the desired kernels.
We could always use "SUBDIR?= GENERIC" to provide the default.
>Do you disagree with the way of adding this meta-information to
>contributed subsystems? I'm all ears for anything better that give
>the same capabilites for external people modifying the system - I just
>haven't found any better way.
As I have previously stated, I view the kernel in the same way that
I view a user-level command. It may require a few unique variants.
However, it is fundamentally,
source (compiled) into object (linked) into executable (loaded) for execution
I see the inclusion of kernel components fitting in in a manner analogous
to the "contrib" structure.
Preprocessors give the standard "include" capability.
As far as the building of a kernel is concerned, the configuration step
can be used to generate a "Makefile" in the object directory and then
invoke it. (Somewhat like the typical "configure" scripts in typical
distributions)
[... deleted: points on Unix and design which I agree with but don't
always find myself bright enough to be able to follow ...]
Summary:
Think "Lego", or, for those old enough to remember, the A.C. Gilbert "Erector"
sets rather than "Microsoft".
Richard Wackerbarth
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130303b197eeb76060>