From owner-freebsd-current Mon Jun 1 04:31:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19875 for freebsd-current-outgoing; Mon, 1 Jun 1998 04:31:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA19870 for ; Mon, 1 Jun 1998 04:31:41 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id GAA07167; Mon, 1 Jun 1998 06:31:33 -0500 (CDT) Date: Mon, 1 Jun 1998 06:31:33 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <19980531235232.04296@follo.net> References: ; from Richard Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500 ; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <19980531052120.41610@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Eivind Eklund From: Richard Wackerbarth Subject: Re: How about /usr/ports/kernel ? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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