In message <Pine.NEB.4.05.10001211829100.1361-100000@audrey.Ivy.NET>,
Miles Nordin writes:

>okay, first of all, my name's Miles, not Mike. 

Oops.  mea culpa. Apologies.


>On Fri, 21 Jan 2000, Jonathan Stone wrote:

>> I am not asking for an embedded OS. I'm asking for robust,
>> remotely-manageable servers.
>[...]
>> > bent around this one Task you're trying to do.

Yes, but that's what serial consoles are *for* :).  That's what you
use them for.  That's what Allen Briggs wants to use them for.

It's a very common usage pattern for servers that have to be
"reliable": you put them in places where the everday erks cant get at
them, and you provide remote managment.

My take is, the problem Matthias is trying to solve is a _different_
problem.  He's' trying to solve a different problem: multiplexing one
physical console amongst machines, without a console/keyboard switch
(KVM switch, they seem to be called here).  If something goes wrong in
the lab, he moves a monitor cable to the machine with the problem to
see the recent console output. And if he wants to debug something, he
attaches a serial terminal to the serial port and types on the serial
terminal keyboard to do a one-time switch there.

All very well, but what we have in the tree is a special-purpose
kludge for that setup, and another for Martin Husemann's (sp) vt-320
or -420.

NetBSD is not about "special-purpose kludges".  I'm on very solid
ground on that one.

>I have also been dealing with this problem for a very long time, too.
>Particularly on PeeCee junk. 

Its neither accurate nor fair to equate current i386 "server"
motherboard hardware with ancient crap like FidoNet or
Fidonet-generation PCs.  If you want to do that, go ahead,
but I'm not interested.  If you want to rant about it, rant at Intel and
Microsoft, not at me. Please.

>I doubt you'd be on this list and using NetBSD in the first place if you
>didn't have a very unique and broad perspective on the industry.  

Not really.  There's others with similar takes.


>Nevertheless, you are one person.  You have chiefly one situation in mind.  
>Others have valuable opinions. 

It depends who we're talking about. 

> It would be great if the serial boot
>blocks worked better for your job, 

Yet again you misunderstand. It would be great if the netBSD
bootblocks worked well and were well-designed.
They dont, and they  aren't.  

There's also an engineering argument about which style of serial
consoles -- lab debugging or server management -- is more important or
more general.  People can _CLEARLY_ do the debugging-style thing with
server-management features.  Simple existence proof: fire up FreeBSD
3.4, and do "help" to the bootloader.  It can do everything Matthias
wants, its better designed, _and_ its configurable.

I think that proves that what we have is not well thought-out.



>people's as well, and they also need to remain a clean, well-coded example
>of how to implement something properly.  


No, Miles.  They SHOULD be a clean, well-coded example of how to
implement somethign properly.  But they aren't.

>I imagine this is true for almost any reader.  I've only used three or
>four architectures myself, but have been positively astounded at the
>strange and interesting ways other comptuers do things.  This experience
>_is_ relevant to the discussion at hand.



>> Mike, please read that FreeBSD URL I re-posted.
>
>It turns out the URL you posted was incorrect, a typo or something.  The
>one I read was:

Oh. Sorry.  No, it wasnt a typo. I did a Gooole search and got that as
a cached page.  guess it moved.

> http://www.freebsd.org/handbook/x9858.html
>
>Their bootblocks do some things ours don't.  I particularly like the
>ability to force serial or screen console without recompiling the boot
>blocks. 

Oh good. So in fact you *do* agree with me.  Did you not notice that,
or do you just like arguing?

>I also like the keyboard probe option.  At the same time, the
>``config file'' stuff is a mess.  It's split across /boot.config and
>/boot/loader.rc, which strikes me as confusing and gratuitous.  I'm not
>sure how this config-file stuff generalizes to network booting, either.

I think it doesn't, _unless_ you also do a multistage network
bootloader: tftp in something that can read files via NFS, then mount
the root, read the "third-stage" bootloader and the config files from
the NFS root.  Either that, or burn the parameters into the PROM image
you use for netbooting.

Personally, I dont think thats such a bad idea at all; we'd'd want to
do something similar to support PXE netboots in any case. Load a sane
Internet-protocol bootloader via PXE, and use that to load the kernel.
That one is less clear, though.

But the bottom line is: where's the mileage in netbooting a
serial-console machine?


>Another thing we need to all get straight:  the -D option to use both
>serial and screen consoles at once is documented to work _only_ in the
>bootblocks. 

There's no call to be patronising. Just who needs to get that clear?
What I was suggesting is adding dual consoles, at least for output, to
the NetBSD kernel.  I said that both on this list and in some detail
to David Brownlee.  I believe I already explained that the ServerBios
serial console does exactly "dual-console", albeit with menus rather
than a CLI.

>> We have _bootloader_ options that need to be persistent.
>
>We have bootloader #define's right now, and a few prebuilt bootloader
>alternatives.  You want to make them into runtime options then?  I agree
>that would be nice.


Miles, are you reading the same bootblock source I am?  We do NOT have
#define's that any sensible person would have #define'd. The code
isnot ameable to either CTS/RTS flow control or true XON/XOFF
(decctql).  It doesnt even build properly with the predefined options
if you have another bootloader built in another directory!

And you think that is a good example?


>I think it needs to be kept really small and simple, though.  I don't like
>the idea of the bootloader not being able to figure out on which console
>the user is sitting until after it has already found a mountable
>filesystem, or perhaps even gotten to the novel ``third stage'' of
>booting. 

Novel?  No, not really.

>Actually, the first stage bootblock probably can't support user
>interaction, but at least you may want to eventually, some day, define a
>bootblock-option that influences where the second-stage bootblock (and
>``config file'') are sought.

First, I'm not sure how that would work. Second, as small motherboards
work their way down the foodchain (e.g, in 1U slates) into the
"server" marketplace, there will be strong market-pressure for this
even in low-end motherboards.  Once BIOs serial consoles become
ubiquitous, the problem ceases to exist: the "console" bios traps
_always_ go to the user, so the bootblocks can just always use that.


[tiny parameter area].

Bad idea. How do you bind option names to option values?  How do you
reserve this across upgrades, from one version fo the bootloader to
another?  How do you _find_ the parameter area?  Will it even fit,
given the bogus "installboot" model which, iirc, means we dont
acutally make a distinction between first- and second-stage bootblocks?


>This preserves the useful feel of Sun's OpenPROM in that you can set
>firmware environment variables both from the 'ok' prompt (which is burned
>into the ROMs) and from the booted operating system using the 'eeprom'
>command:

But that kinda assumes that openprom is a good model, when in so many
ways it just isn't :-).  If you ever had to do a PROM upgrade on a Sun
you would know what I'm talking about.


>If we are to follow NCD's example and have two config files (a small
>machine-readable first-stage configspace and a larger, human-readable
>config file), I think we should also try to follow the spirit of their
>work by making the first-stage config space a subset of the config file.

Yes. If we do the first-stage thing at all, that'd be a requirement,
not an option.


>first-stage {...} would be encoded by installboot and written into the
>32-to-96-byte configspace in the first block.

You think the installboot design is a good idea too?
You do know opinion on that is sharply divided?


>Of course, if you're going to write the code you are totally free to
>disregard my ideas!  I thought that'd be a really sweet way to do it,
>though.  Much nicer than LILO's way of stuffing them into a ``map'' file
>that was ``special'' and couldn't even be edited with a text editor at a
>single-user shell, much less changed from the boot prompt!


Mewrite the code?  In feburary, after SIGCOMM, as (I beleive) I said
earlier. But I think the people who committed the kludges also have a
moral obligation to do something to repair some of the damage they did.


>> But we dont have one-time overrides.
>
>That's not completely true.  That's exactly what we do have.  All the boot
>options (-s, -d, -a) are one-time overrides.  For overrides of more
>complex variables inside the kernel, we have ddb, which replaces Linux's
>``kernel command line.''

But Miles, those options are for the kernel. I was talking about
options for the _bootblocks_.  I said as much, too.


>What we don't have, is any way to customize boot block behaviour without
>recompiling them.

>Okay, we differ here.  I feel that if you're willing to learn ``more,''
>more than usual, then ddb is a perfectly acceptable replacement for kernel
>command lines.


You're welcome to your opinoin, but I hope you dont take offense if I
no longer give it much credence.

Would you have used NCDs, if you had to use an atrocious

>However, I think this is a dead issue.  We aren't arguing about it,
>because your project hasn't yet run into a problem that requires
>ddb-on-boot optionsetting.

No, Miles. This  has nothing to do with "my project" or what I've run
into.    I have gotten private email from quite a few people agreeing
that  the functionality I'm talking about is needed.   I dont
see anyone disagreeing with that, not even Matthias or Martin.

Even you, when you bother to look at facts rather than just rant, seem
to be agreeing with me.









~
>> NetBSD does NOT automatically select consoles.
>
>whoa, no, this is _really_ key to what I've been saying here.  NetBSD
>absolutely _does_ have code to do this. 

No, Miles, it DOES NOT. I tried it. I read the docs. I read the source
code. It DOES NOT.  I tell you three times.

What it has is code to detect serial input on a serial console and use
that serial device as serial console, instead of using the video
display and keyboard. That is _not_ autodetection. Its a dynamic
redirect which qruires _human_ _intervention_ within a critical timing
window to switch to the serial console.

>I don't use it myself, but have
>every reason to believe it works.  Because this is so hard to do on the
>PeeCee, it's complex--it can tend toward the screen, or tend toward the
>COM port.  It can be based on the presence or absence of COM hardware, or
>it can explicitly require a keypress on the chosen console.  It _can_ be
>set up to use one console most of the time, but offer to use the other if
>the user presses key there.

Miles, thats simply not true, and thats why I have been complaining.

In general, its a bad idea to make claims that overstep your
knowledge, its worse idea to bear false witness, and its a really bad
idea to tell lies. I dont think you're lying, but you are definitely
doing one of the other two.

Please don't.


>The problem is, it doesn't work with your @#%$ ServerBIOS hack!  The
>reason it doesn't work, to me, looks like ``because ServerBIOS is broken,
>and was foolishly implemented from the beginning.'' ServerBIOS undermines
>and befuddles the bootblock's ability to auto-detect the console.  And,
>given what you've told me about it, it's unreasonable to expect an
>operating system to do any better than NetBSD does when it's got
>ServerBIOS running over its head and deliberately maximizing confusion.

Miles, that's wrong too.  ServerBIOs serial cosoles aren't "my hack".
they're not even a hack .They expand the semantics of PC prom I/O, so
that it is *the same*, repeat *the same* semantics as console I/O
calls on Suns or DEC hardware: instead of going to the VGA screen or
from the kbd, "console" output now goes to some soft-configurable
"console" device.  That might be VGA, or a serial port (with speed,
flow control, etc) set by the user, or both: the client of the BIOS
doesnt need to know or care.

To put it another way, PC cosole I/O now does exactly what the
"write to console device" does on a DEC or a Sun.  It's no more of
a hack than the DEC or the Sun PROm console I/O.

True, bootblocks now need to be a little better designed: they need to
ask the BIOS what the underlying device is and use the same device as
console.  But DEC and SUN kernels do that, too. The i386 bootblocks
just need to step away from DOS hackery and use a little more good
engineering. 

But once again, in case the point got lost: with FreeBSD, all I had to
do was add one option to /boot.config.  With the gross kludges, I'm
sunk without a trace. And so is anyone else wanting to use this, er,
dare I say defacto industry standard?


The rest doesn't seem worth answering.