> The only problem is that reading bootblock or kernel options out of a
> file in / doesn't generalize at all well to netbooting.

I think the way to fix this is to put a small buffer into the boot program,
containing environment variables and some dead space. Surround it with some
magic numbers, so we can scan the bootprog file for it. Provide a utility to
read/edit/write it (like disklabel), with reasonable sanity checks. Add some
simple logic on the boot prompt to allow overriding of variables by users:

	boot console=com0 wd0a:/netbsd

A sicker way to do this would be to have the boot program be ustarfs, and
read its own table-of-contents to find the config file. Or to reuse the
mdsetroot stuff we already have for install kernels. There are lots of
valid ways to do this.

Anyway, the idea is to get the benefits of the config file approach but
without the requirement for too-early filesystem access. I agree the method
can be abused horribly, but if there's one group I trust to restrain code
from featuritis, it's the NetBSD crowd.

> Personally, I think dual consoles (a device that outputs kernel
> printfs, ddb output, etc. to both VGA display and serial console, and
> ideally, accepts input from either) a better solution to just about
> all of these problems.

I prefer this too. But it is definitely far enough in the future that a
mid-term solution involving the boot blocks makes a lot of sense.

Todd Whitesel
toddpw @ best.com