From owner-freebsd-hackers  Tue Jun  9 13:32:38 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA28404
          for freebsd-hackers-outgoing; Tue, 9 Jun 1998 13:32:38 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27637;
          Tue, 9 Jun 1998 13:29:35 -0700 (PDT)
          (envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id WAA21923;
	Tue, 9 Jun 1998 22:27:20 +0200 (CEST)
To: Jun-ichiro itojun Itoh <itojun@iijlab.net>
cc: Mike Smith <mike@smith.net.au>, core@FreeBSD.ORG, hackers@FreeBSD.ORG,
        tech-jp@jp.freebsd.org
Subject: Re: new config 
In-reply-to: Your message of "Wed, 10 Jun 1998 00:07:45 +0900."
             <10481.897404865@coconut.itojun.org> 
Date: Tue, 09 Jun 1998 22:27:20 +0200
Message-ID: <21921.897424040@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I have spent much time on the question of configuration, and because of
lack of time I have not implemented my conclusion.

Not that it would take long time to implement, quite the contrary,
but because it would take long time to fight the battles against
the "traditionalists"

Basically:

	1. Kernel contains a filesystem (MFS kind of thing).

	2. Kernel initializes and mounts MFS as root filesystem.

	3. Userland programs on the MFS, preferably in script form,
	   direct the probe and attach process.

	4. The last part of the configuration script mounts the
	   quasi-root on "/rootfs" and establish symlinks to
	   make things look like they used to:

		for i in etc bin sbin usr var tmp
		do
			ln -s /rootfs/$i
		done

	5. Delete files no longer needed on the MFS to preserve RAM


This has many advantages:

	1. Device probe and attach happens in a "normal environment"
	   timeouts work, you can microcode from files (from the MFS)

	2. Much more complex instructions can be given to the driver
	   at probe/attach time, without bloating the kernel.

	3. You can probe/attach devices later on if you feel like it.

	4. Loadable drivers will not be different from normal drivers,
	   infact all drivers could be loadable and stored on the MFS,
	   if they didn't find anything, we unload them again.

	5. User has full control over probe/attach process

	6. There is nothing magic about fsck'ing the rootfs.

	7. There is nothing magic about the rootfs

	8. Probe / Attach can easily be made interactive, vastly
	   adding to the flexibility of the userconfig scheme.


The few problems:

	1. How to control the contents of the MFS filesystem.

	2. Change drivers to probe/attach in civilized environment

	3. Fix MFS to consume memory "as needed" only.

	4. Convince the traditionalists that this is the right way
	   to do things.


References:

	AIX does it pretty much this way.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
"ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message