On Thu, 20 Jan 2000, Jonathan Stone wrote:

> Yep. If it were up to me, I'd consider a three-stage loader, like
> FreeBSD's current loader. I did post a URL to the handbook entry for
> that. Which nobody read, right?

Could you (re)post this please?  I couldn't find it easily.

You're right that I didn't read the URL's you posted, but that's because
they pointed to Intel's and VA Research's sites.  Since I hate both
companies, I figured reading their ads and white papers would waste my
time.  You'll have to admit that the likelihood of my reading Intel's
marketing drivel about EMP and suddenly changing my mind about how stupid
it is--it's pretty low.  Hopefully others with a stronger commitment to
Intel technology gave them a look.

> 	``The bootblocks are perfect.  Our bootblocks already do
>         everything anyone needs. You're just too stupid to understand
> 	that you are trying to do the wrong thing. Here's what
> 	you should be doing instead!''

Yes, that is pretty much exactly what I believe.  Except I would probably
say ``diabolically misled'' rather than stupid.

My style of disagreement tends to involve mockery, so it makes sense that
people are often inclined to take it personally, but please don't!  At any
given moment, I usually disagree with almost everything I believed one or
two years ago.  I used to be a member of FidoNet, and wrote a 500-line DOS
batch file.  talk about ``beneath contempt!''

NetBSD:  it sucks less.

I haven't been offended by anything you've said so far, and hope the same
holds true for you.  If not, well, uh, i'm sorry.  Hopefully everyone
understands I tend to hold extreme opinions--please don't take me too
seriously.

I think part of the point here is that it's extremely difficult (but not
necessarily unadviseable) to productively disagree with programming
decisions when you're writing on a list where the authors hang out.  It's
likely to be taken personally, and what's worse is that they might be
tempted to argue with you rather than writing more code for us!  So,
you're definitely in a difficult spot.

Recently, your suggestions have become more specific, sensical, and
perhaps useful than what I originally thought.  The problem for me is that
I want to make sure you don't I don't want to see years of trial-and-error
history with lots of subtle implications bent around this one Task you're
trying to do.

Especially since you're using disgustingly awful technology to do it, and
it doesn't make sense to blame the problems of this technology which you
_can't_ change (EMP, Phoenix BIOS), on NetBSD which you _can_ change.  
All you end up doing is corrupting and disgustifying NetBSD.  As long as
the changes you provide are generalizable, don't break working
installations that are simpler than yours, and don't merely rearrange the
defaults to match Phoenix EMP Server BIOS Document 454-234A10-x, I'm all
for including them in the boot blocks.


As for LILO, it seems you're right that we don't have a persistent boot
option storage system.  However, we also don't seem to have any boot
options that need to be stored persistently yet.  The ones I know about
are -s to boot single user, -d to enter the debugger, and, what'sit, -a to
prompt for a root filesystem?  All of which are fairly interactive.  
Maybe such a thing could eventually become useful, although I can't
envision the need at the moment.  However I don't think it's fair to
compare with LILO--we have other (persistent) ways of handling all the
things LILO needs append= options for.

 o To quickly test something that would have been an option in Linux:
    ddb-on-boot
 o To store such changes persistently:
    kernel config files

The NetBSD architecture, as usual, requires you to learn more.  but, the
things you learn are useful.  You're less likely to need to use the
feature at all in the first place, because NetBSD does not flippantly
assign kernel options to things that can be done automatically (like
Linux's console= and root filesystem selection). And the underlying code
is superior from a developer's perspective, not to mention more
machine-independent.

Linux has neither a debugger nor a good configuration architecture, so:
 o They have to compile option-parsing code into every driver, instead of
   doing it generically with ddb like we do.  This is bad, because the
   options do not have a uniform format or uniform parsing code, and
   kernel code-maintenance/size is wasted on redundant and unnecessary
   work.
 o They have three different syntaxes (and three different ``stubs'' in
   the driver) for every given option: one for the kernel command line,
   one for the loadable module, and one for the configuration-madlib
   script.  Any of the three may be half-implemented or simply missing
   (for example, see the aha1542 module).
 o They can't rebuild kernels flippantly just to change one option,
   because they don't have the good Makefile system that we do.  Changing
   one option requires 'make dep && make clean && make bzImage', else you
   get unpredictable (sometimes, working) results.

Having minimal or none persistent storage in the boot blocks is good for
new developers who don't understand this strategy, because it encourages
them to DTRT without necessarily realizing it.  But, that's probably not
why we've got them.  More likely it's because that's what original BSD and
most vendor Unixes do.

This sort of thinking is even better considering NetBSD's embedded-OS
future.  Changing a config file and rebuilding is a lot less crufty than
writing a custom loader to pass information.  There's less custom in-house
code to provide, fewer subsystems to break, and less client-side state.

When I first quit using Linux I was surprised, confused, and dissappointed
to see that the kernel ``command line'' had basically dissappeared.  
Right now, I'm irritated and indignant that I ever had to deal with it in
the first place.  I definitely don't miss the thing.

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US