Date: Tue, 29 Apr 1997 19:14:05 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: config@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: Startup userconfig parsing Message-ID: <199704290944.TAA21477@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704290927.TAA29118@godzilla.zeta.org.au> from Bruce Evans at "Apr 29, 97 07:27:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans stands accused of saying:
> >Put all our stuff in /boot on the boot filesystem. If /boot/kernel.rc
> >exists, it's loaded unconditionally. If /boot/kernel.rc.<kernelname>
>
> It shouldn't be in a subdirectory. Putting it in the root directory
> allows simpler file systems and simpler fs support in the boot loader.
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.
> The main config file belongs in the _root_ file system next to the kernel.
> Only configuration info for the boot loader belongs in the boot file
> system.
I appreciate the distinction.
> >Now, assuming that the space just after the kernel is available, I
> >propose a header, something like :
> >
> >0xmagicnumber, 0xlength,
> >"rcfile 1 name"
> >"line 1"
> >"line ..."
> >0xmagicnumber, 0xlength,
> >"rcfile 2 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?
I feel that some rudimentary structure is required. Magic-numbering
with length values is about as simple as I can come up with.
> >A suitable API for modules to extract this information can be devised.
>
> getc().
Not useful, as the information is consumer-driven and it's not at all
clear who the consumer(s) are likely to be.
> >For userconfig stuff, entries would probably be plain userconfig commands
> >prefixed appropriately, eg. :
> >
> >userconfig port ed0 0x300
>
> If the commands are unique then you don't need keys to say which subsystem
> should parse them.
Perhaps, but it's much easier to say :
cp = NULL;
while ((cp = kern_getnextenv("userconfig", cp))) {
process_var(cp);
}
than anything else that you can do from the consumer's side without
tagging the data.
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.
The only alternative that I can think of would involve a linker set for
command handlers, and that loses for LKMs.
> Bruce
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704290944.TAA21477>