From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 21 01:03:53 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 82D9B16A4CE; Wed, 21 Jul 2004 01:03:53 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4830A43D2D; Wed, 21 Jul 2004 01:03:53 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i6L13gOF009050; Tue, 20 Jul 2004 18:03:42 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i6L13gZw009049; Tue, 20 Jul 2004 18:03:42 -0700 Date: Tue, 20 Jul 2004 18:03:42 -0700 From: Brooks Davis To: "Conrad J. Sabatier" Message-ID: <20040721010342.GA8398@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org 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:03:53 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: > Just musing on an idea here: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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?=20 > 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. 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. 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? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFA/cDtXY6L6fI4GtQRAqJ2AKCmdRcXaKKJyXTUNphL49rb2o0GygCfV5/n FR230TjAQU6M0xhXj4BrJcw= =pByA -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--