From owner-freebsd-config Tue Apr 29 03:33:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA09564 for config-outgoing; Tue, 29 Apr 1997 03:33:34 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09559 for ; Tue, 29 Apr 1997 03:33:32 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id DAA03474 for ; Tue, 29 Apr 1997 03:33:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA31045; Tue, 29 Apr 1997 20:26:08 +1000 Date: Tue, 29 Apr 1997 20:26:08 +1000 From: Bruce Evans Message-Id: <199704291026.UAA31045@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 >Is the bootloader currently stressed by the current filesystem? I >specifically asked about subdirectories when you first mentioned the >readfile() support, and you scoffed at the intimation that they might >be a problem. It's squeezed by the 7.5K limit. >> >0xmagicnumber, 0xlength, >> >"rcfile 1 name" >> >> Overengineered. > >Perhaps. Perhaps not. What if I want to throw in, say, the splash screen >image here. Am I still overengineering? How about the initial state >for the kernel's registry? The count would be very painful to maintain using ed(1) when you're fixing a failed config after screwing up the driver for the device containing /usr... The splash screen could be just another file to load. It could be handled by a bootstrap load command and a bootstrap or kernelconfig splash command. >I specifically don't want to require that the "environment"-management >code know all of the possible consumers of a a variable. Some may >provide state, some may be commands; they should be transparent to the >management code. ed(1) certainly won't know about what the commands mean :-). Bruce