From owner-freebsd-arch@FreeBSD.ORG  Mon Oct  4 10:15:00 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2611316A4CE
	for <arch@freebsd.org>; Mon,  4 Oct 2004 10:15:00 +0000 (GMT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7F01243D55
	for <arch@freebsd.org>; Mon,  4 Oct 2004 10:14:59 +0000 (GMT)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i94AEvxw001689
	for <arch@freebsd.org>; Mon, 4 Oct 2004 12:14:57 +0200 (CEST)
	(envelope-from phk@critter.freebsd.dk)
To: arch@freebsd.org
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 04 Oct 2004 12:14:57 +0200
Message-ID: <1688.1096884897@critter.freebsd.dk>
Sender: phk@critter.freebsd.dk
Subject: /sys/conf is getting unwieldy to handle...
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2004 10:15:00 -0000


I think somebody® should start to look at our kernel configuration
mechanism now so that we can have something better for 6.x.

I am sure that there are 257 ways to do this much better and that
at least 5% of these solutions involve XML and 10% involves java
and graphical userinterfaces, and at least a 24 bit colorspace for
the bikeshed.

I think a lot can be done with some very simple changes, and I think
more userfriendly tools can be written on top of any sensible "run
this ascii-file through this too" model, so lets try to leave the
rocket science out of this for now and just improve on the scheme
we all know and love.

I would love to see a dedicated band of merry men go off in a corner
somewhere and "just do it"®  Any takers ?


Here is a strawman to think about:

Split GENERIC into a number of files:

	PROD.conf
		standard stuff for a production environment kernel.
		Stuff like UFS, CD9660 etc goes here.

	DEBUG.conf
		Adds the current canonical debug options.

	ATA.conf
		Adds ata drivers

	USB.conf
		Adds usb stuff

	FIREWIRE.conf

	IPV6.conf

	SCSI.conf

	NETGRAPH.conf

	IPFW.conf

	IPF.conf

you get the idea.

The actual GENERIC file would then look like:


	ident GENERIC

	include PROD.conf
	include ATA.conf
	include USB.conf
	include FIREWIRE.conf
	include SCSI.conf
	...


And people can create kernel config files which will be much more
resistant to feature addition:

	ident MYKERNEL

	include PROD.conf
	include ATA.conf
	nooption ataraid
	include IPFW.conf

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.