In message <200001201518.KAA02129@ghost.whirlpool.com>Andrew Gillham writes:

>Err, I thought it was "My EMACS is hard to use when ^Q/^S means something to
>the serial port."

No. Its mostly the strong recommendations to use hardware handshake
for the ServerBios serial consoles.  (Why does nobody _listen_
when I say that? Or read the URLs?)

All the docs and setup I've seen for the serverBIOS serail-console
feature recommend hardware handshaking.  Perhaps Intel et.al. are
worried about people using modems to do remote BIOS access.
I dunno, but thats what they say.  But emacs? yes, Pretty much. only
s/hard/impossible/ :)

And last but not least, the bootblocks dont do the XON part of
XON/XOFF. For pity's sake, if you're going to do XON/XOFF at all, do
decctlq.  Especially if it's for a DEC terminal. And if not, document
that, rather than just calling it XON/XOFF.  I mean, really.

>Sounds a bit like an application problem.

Nope.  That's a reason, but not the main reason. Check the URLs I
posted.  See what they recommend for the BIOS serial consoles.
(Or ask Herb what his Weasel does? I dunno, but I'm curious).



>> But in Jonathan's case, if his terminal server (or whatnot) is set for
>> hardware flow control, he won't be able to type commands at the boot
>> prompt, because the bootblocks aren't bringing CTS high.

Matthias says he just fixed that.  Full credit to him for that.
I really do appreciate all the help I've gotten.


[snip]

>Currently XON/XOFF is the default for DIRECT_SERIAL?  If there are people
>on either side of the issue (e.g. Jonathan's terminal server forces RTS/CTS,
>but other want the simple convenience of a "laplink cable") I don't think
>changing the default is the right thing to do.  

Nope.  Thts not it at all. Some foolish person made DIRECT_SERIAL
synonomous with DIRECT_SERIAL plus XON/XOFF. There's _no way_ to stop
the bootblocks doing XON/XOFF, if you turn on DIRECT_SERIAL.  And it
woudln't be a big deal, if it wasn't for trying to make out that this
isn't a problem, or wasn't a foolish thing to have done in the first
place, or that it shouldn't be fixed so the defalt is consisent with
the non-DIRECT_SERIAL (BIOS serial) case.

Changing the default *is* the right thing to do.  End of story, as far
as I'm concerned.  Sure, add hooks for both, but change the default.


[reordered]

>I think some people may have been offended by the "this is all crap because
>it doesn't do what I want" tone of some messages.  Read them again if you
>think I am exaggerating.

Nope.  the message is not that the bootblocks are all crap because
they dont do what I want.  The message is that the bootblocks are
crappy, because they *are*.  See above.  And read too the messages
with a tone of:

	``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!''

which is, surely, equally offensive.


>Adding the ability to
>build bootblocks that do *require* RTS/CTS is a good thing though. 

Clearly I didn't express myself well.  It's not the absence of a hook
to do RTS/CTS that i'm griping about.  It's the inability to turn
XON/XOFF *off* which deserves (and got!) brickbats. The inability to
concede that a mistake was made, or even to allow fixing it, just
makes it worse.

And that's not XON/XOFF: it's just XOFF.  To me, XON/XOFF means
decctlq.  That's not what the bootblocks do. Typing anything at the
keyboard after an XOFF will let the bootblocks start sending, even
though the terminal may wnot have drained its input buffer.  That can
cause overruns.  If the feature really was designed for a DEC
terminal, that's a bug.


>How about listing requirements for serial consoles, then ranking them
>by required/nice to have/whatever, and try to get some consensus amongst
>the developers?

Yes indeed. Why not? Why wasn't that done to begin with?  That's how
NetBSD is supposed to work. It didn't, in this instance. That means
that either the design process fouled up, or perhaps that people who
should have gotten involved, didn't.

But the message I sent to Matthias yesterday is a pretty good starting
point; it lists the design choices where the design choices in current
bootblocks are lousy choices for permanently-connected serial
consoles.  Maybe we can make some progress on that.


>Personally I think modeling the i386 bootblock/bootprocess off of a "real
>machine" like a Sparc or Alpha would be excellent.  Having the ability to
>switch a cable back and forth between my PC164/SS10/i386 and not have to
>worry about wiring and other stuff would be a benefit to me.  A two stage
>boot process would be nice also, considering things like PXE, Award BIOS
>utilities like CBROM, etc.

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?


A three-stage bootloader can use its filesystem-reading code to read
bootloader parameters out of a file in the `a' partition of the
FreeBSD slice of the boot disk. That's what FreeBSD does.  No more
crap with compile-time options, or the `installboot' hack with the
filesystem, or clobbering all your the serial bootblock parameters if
you upgrade.  You could configure options for the bootloader 
to pas onto the kernel the same  way.    Heck, even LILO can do that.