From owner-freebsd-hackers Tue Jun 9 14:03:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA04642 for freebsd-hackers-outgoing; Tue, 9 Jun 1998 14:03:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA04399; Tue, 9 Jun 1998 14:02:10 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Tue Jun 9 16:02 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id QAA16763; Tue, 9 Jun 1998 16:02:02 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id ; Tue, 9 Jun 1998 17:01:40 -0400 Message-ID: To: itojun@iijlab.net, phk@critter.freebsd.dk Cc: mike@smith.net.au, core@FreeBSD.ORG, hackers@FreeBSD.ORG, tech-jp@jp.freebsd.org Subject: RE: new config 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 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message