Date: Wed, 30 Apr 1997 17:07:38 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, config@freebsd.org Subject: Re: Startup userconfig parsing Message-ID: <199704300737.RAA27393@genesis.atrad.adelaide.edu.au> In-Reply-To: <199704300633.QAA08781@godzilla.zeta.org.au> from Bruce Evans at "Apr 30, 97 04:33:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans stands accused of saying: > >> It's squeezed by the 7.5K limit. > > > >Any reason this can't be 8.5K these days? Who boots from 15spt media > >anymore? > > 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. > >I think you are misunderstanding what I am suggesting. The file(s) to > >load can be specified in any fashion; if you want to put the > >instructions as to what to load in a file itself, that's fine. The > > It's overengineerd, not fine. At this point, I'm inclined to seriously question whether you would consider anything other than a rock to be appropriately engineered. 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. The only accessible storage is memory. The only way to get stuff into memory is to have something before the kernel shove it there. The only thing that runs before the kernel is the bootloader, ergo the bootloader has to get the information there. Now, how do we know what it is? We put some identifying information in there. How do we know where to find things? We use a size value to tell us where the next one is. This isn't "overengineered". Writing a ramdisk filesystem engine is "overengineered". Saying "we can't do this because it's more featureful than what we currently have" is not helpful. Without explaining your criteria or objections, "overengineered" is quite insulting. > >> ed(1) certainly won't know about what the commands mean :-). > > > >Huh? Sorry, I missed that one altogether. > > Config files are prepared with a text editor. Not necessarily. And at any rate, the entity editing the data is 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. wrt. your comment on kernelname; MHO (probably overengineered again) suggests that the bootinfo should perhaps be located somewhere sane and preserved rather than having to copy it around. "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. Any idea if this is even vaguely feasible? The kernel virtual allocation stuff at in cpu_startup() doesn't look like it understands being told where the physical allocation should go. > 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?199704300737.RAA27393>