From owner-FreeBSD-tech-jp@jp.freebsd.org  Wed Jun 10 06:02:13 1998
Received: (from daemon@localhost)
	by jaz.jp.freebsd.org (8.8.8+3.0Wbeta13/8.7.3) id GAA09731;
	Wed, 10 Jun 1998 06:02:13 +0900 (JST)
	(envelope-from owner-FreeBSD-tech-jp@jp.FreeBSD.org)
Received: from att.com (kcgw2.att.com [192.128.133.152])
	by jaz.jp.freebsd.org (8.8.8+3.0Wbeta13/8.7.3) with SMTP id GAA09725
	for <tech-jp@jp.freebsd.org>; Wed, 10 Jun 1998 06:02:10 +0900 (JST)
	(envelope-from sbabkin@dcn.att.com)
From: sbabkin@dcn.att.com
Received: by kcgw2.att.com; Tue Jun  9 15:42 CDT 1998
Received: from dcn71.dcn.att.com ([135.44.192.112])
	by kcig2.att.att.com (AT&T/GW-1.0) with ESMTP id QAA23905
	for <tech-jp@jp.freebsd.org>; Tue, 9 Jun 1998 16:02:02 -0500 (CDT)
Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49)
	id <MQNK3MKR>; Tue, 9 Jun 1998 17:01:40 -0400
Message-ID: <C50B6FBA632FD111AF0F0000C0AD71EEFF8B22@dcn71.dcn.att.com>
To: itojun@iijlab.net, phk@critter.freebsd.dk
Cc: mike@smith.net.au, core@freebsd.org, hackers@freebsd.org,
        tech-jp@jp.freebsd.org
Date: Tue, 9 Jun 1998 17:01:38 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Reply-To: FreeBSD-tech-jp@jp.freebsd.org
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha) patchlevel=24]
X-Sequence: FreeBSD-tech-jp 1513
Subject: [FreeBSD-tech-jp 1513] RE: new config 
Errors-To: owner-FreeBSD-tech-jp@jp.freebsd.org
Sender: owner-FreeBSD-tech-jp@jp.freebsd.org

> ----------
> From: 	Poul-Henning Kamp[SMTP:phk@critter.freebsd.dk]
> 
> I have spent much time on the question of configuration, and because
> of
> lack of time I have not implemented my conclusion.
> 
That's a really great concept!

> 	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
> 
Alternative approach: mount the traditional root filesystem
on /, and the config-filesystem on /stand or something like.

> The few problems:
> 
> 	1. How to control the contents of the MFS filesystem.
...
> 	3. Fix MFS to consume memory "as needed" only.
> 
Because this filesystem is almost-read-only (files can only be
removed), it can be very simplified. In the simplest case, it
can be just a tar image of this filesystem added to the end
of the kernel image. The bootstrap code will automatically load
it into the memory. The speed of lookup is not important,
so the simple contiguous tar image is perfect. Each page
can be freed after all files in the image located in this page
are removed. This will need some changes to the VM subsystem
that will have to recognize this tar image after the end of
kernel image in memory.

-Serge

