From owner-freebsd-config Wed Apr 30 01:42:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA16228 for config-outgoing; Wed, 30 Apr 1997 01:42:12 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA16223 for ; Wed, 30 Apr 1997 01:42:09 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA13095; Wed, 30 Apr 1997 18:37:30 +1000 Date: Wed, 30 Apr 1997 18:37:30 +1000 From: Bruce Evans Message-Id: <199704300837.SAA13095@godzilla.zeta.org.au> To: bde@zeta.org.au, msmith@atrad.adelaide.edu.au Subject: Re: Startup userconfig parsing Cc: config@freebsd.org Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Yes, only 8K is reserved for the boot blocks, and 15spt media is not >> uncommon. > >Hmm. Full-circle back to the three-stage boot I guess. Nope. That would be overengineered. >At this point, I'm inclined to seriously question whether you would >consider anything other than a rock to be appropriately engineered. `cat' with no options was fine :-). >How would you go about "rightsizing" the proposal then? Consider : it is >desired to be able to access arbitrary, user-specified configuration data >from a data entity other than the kernel, for use in the kernel prior to >the availability of filesystem or network services. No, it's desired to have no user-specified configuration data then. Userconfig etc. are "temporary" kludges to get around h/w and BIOS braindamage. >> Config files are prepared with a text editor. > >Not necessarily. And at any rate, the entity editing the data is Necessarily, by definition :-). >expected to perform the interpretation. I still don't understand how >ed is meant, one way or another, to have anything to do with arbitrary >data intended for consumption by the kernel. boot: -s ... # mount / # ed /boot.config # fix up booting problems # ed /etc/fstab # fix up mounting problems ... >"sane" is a difficult question. It'd be good to have the area created >by the bootloader preserved as part of the kernel's space, at least until >the information could be copied into a malloced area. Page 0 is always preserved, and there's 2.5K or 3.5K to spare in it. This is a nice limit for a config file size (stops you from overengineering it :-) but is too small for splash screens. It would probably be simplest for the bootstrap to put things below 640K and delay use of some pages below 640K. Bruce