From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 01:29:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EF0016A4CE; Wed, 21 Jul 2004 01:29:39 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80C543D2F; Wed, 21 Jul 2004 01:29:38 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Bn5vN-0004Hp-00; Wed, 21 Jul 2004 03:29:37 +0200 Received: from [84.128.141.84] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Bn5vN-0006uW-00; Wed, 21 Jul 2004 03:29:37 +0200 From: Max Laier To: freebsd-hackers@freebsd.org Date: Wed, 21 Jul 2004 03:27:22 +0200 User-Agent: KMail/1.6.2 References: <20040721010342.GA8398@Odin.AC.HMC.Edu> In-Reply-To: <20040721010342.GA8398@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Bac/AGbBUnTVzB7"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407210327.29307.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-config@freebsd.org Subject: Re: "Next Generation" kernel configuration? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 01:29:39 -0000 --Boundary-02=_Bac/AGbBUnTVzB7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 July 2004 03:03, Brooks Davis wrote: > On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > > Just musing on an idea here: > > > > I've been thinking for a while now about trying to write a tool to make > > kernel configuration easier, sort of a "make config" (as in ports) for > > the kernel, similar to what's available on some of the Linux distros. > > > > Ideally, such a tool would be capable of automatically adapting itself > > to handle and present as choices, in an orderly and logical fashion, > > whatever devices, options, etc. were currently available, as defined by > > the files in /sys/conf et al. > > > > The major hurdle to overcome, it appears to me, is that the scheme > > currently employed to describe the available devices, options, etc. > > does not lend itself very easily at all to any kind of automatic > > parsing or other manipulations. Determining dependencies between > > components programmatically, for one thing, seems well near impossible. > > The NOTES files, in their current form, make even finding the comment > > associated with a particular option or device extremely difficult, if > > not impossible. > > > > Has this ever come up for discussion before? Now that we have rcNG, > > with its explicit declarations of dependencies, has any thought been > > given to doing something similar with kernel configuration files? > > Something still human-readable, yet more orderly and systematic, easier > > for a machine to interpret, present and verify? > > There have been previous discussions. They should be visiable in the > archives if you can find the magic search strings. > > > A dependable tool offering a menu-driven means of configuring the > > kernel, ensuring proper config file syntax, dependency handling, > > prevention of incompatible options, etc. -- as well as online > > documentation, advice, suggestions and warnings, plus perhaps a nice > > set of default selections -- would be a very nice addition to the > > system. But to bring it about, obviously a major reworking of the > > current system of kernel configuration files would be required. > > You can have my simple flat file kernel config when you pry it from my > cold, dead hands and I know a number of other develoeprs share this > viewpoint. All my experiences with the linux visual kernel config tool > have been annoying and I've got friends with more expierence with it > that have much less kind things to say. Add me to the list. And this realates to sys/conf/* as well (respondig to t= he=20 re-reply). Especially developers prefer *clean*, *simple* config files and = I=20 (personally) would really really hate to twiddle with some insane XML just = to=20 add something to the build! > That said, so long as it doesn't impose too much developer burden, > an improved set of backend files that did a better job of handling > dependencies and knew which options where relevent given the configured > set of devices could be useful. http://www.freebsd.org/releases/5.3R/todo.html has a "Desired features"-ite= m=20 saying: "Revised kld build infrastructure", which will pretty much interfer= e=20 with this. You might want to contact with the current owner (peter@) and he= ar=20 what he has to say. Other than that, I'd welcome a somewhat enriched config= =20 environment as long as it is done reasonable and makes the job easier! And= =20 please: NO XML! > There is a valid question of what a depenency means. For instance, you > can't really have IP networking without lo(4) (there's a null pointer > derefrence if you try), but since you can load it as a module, should > you have to compile it in? There should be levels of dependencies ... i.e. the TBD config-tool would=20 (strongly) suggest that you build-in lo(4) into an "options INET" kernel, b= ut=20 should not stop you to do else. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_Bac/AGbBUnTVzB7 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBA/caBXyyEoT62BG0RAiBVAJ4qxg1UcSPtME3K6DfaqdOEtWahlQCffcBO Ic3LNMcpcEj/HVQdrBMkqaQ= =b9p+ -----END PGP SIGNATURE----- --Boundary-02=_Bac/AGbBUnTVzB7--