jonathan@Cuisinart.DSG.Stanford.EDU said:
>  Exactly when did the bootblocks start passing console-device info up
> to the kernel? 

RCS file: /cvsroot/syssrc/sys/arch/i386/i386/machdep.c,v
[...]
revision 1.255
date: 1997/09/20 12:51:13;  author: drochner;  state: Exp;  lines: +58 -33
-define a buffer for information passed by the bootloader
-add a function ("lookup_bootinfo") to extract data
-use passed console information, if present, for console attachment
-arrange definitions for console and KGDB device a bit nicer
[...]

This was before 1.3, and it hasn't changed significantly in the meantime.

> Anyone object to adding pointers to boot_console(4) to
> the comments in GENERIC about serial consoles?

No. But it is not really appropriate. The information (as far as the
kernel is concerned) should be in console(4), and if it is insufficient,
it should be improved there.

[another mail]
> Seems like the test for the provided "biosboot_com0" bootblocks is
> exactly inverted: normal "internal" console, unless someone hits a key
> on the serial console. I cant think of _any_ sane use for that.

The keypress thing shouldn't be used in the provided "biosboot_com0".
It is useful for me however: I use a lot of singleboard computers
without monitor, keyboard nor serial terminal connected. In case of trouble
I can connect a monitor and get at least the last 25 lines of console
output, which would be lost with a serial console. (I don't have tens
of terminals to connect one to each SBC...) If serious debugging is
needed, I connect something to the serial line and don't need to knee
in front of the rack within the experiment area (radiation exposed btw).

> And forcing XON/XOFF with DIRECT_CONSOLE is just ... broken, given the
> existence of BIOS serial consoles which want RTS/CTS hardware handshaking.

So don't use it, or implement an option which fits your needs.
It is intended and documented that DIRECT_CONSOLE uses software
handshake. Some people (including me) want it that way.

> Meanwhile, the console(4) manpage is woefully out of date.

It's quite accurate. There might be a better wording for some
things, but the information is correct afais.

> PeeCee server motherboards are real
> computers, with microcontrollers to do EMP (remote front-panel
> reset/power-on over a serial wire), and BIOS options to use serial
> consoles.  For which the BIOS would really rather use CTS/RTS
> handshaking, it wants DCD asserted, the speed is configurable up to
> 19.2k or 56k or 115200,

A BIOS which redirects console output behind the application's back
does not make up a real computer for me. At least, if the OS has no
way to detect what happened. Or is there one, and also a BIOS
interface which allows to set baudrates >9.6k? Point me to the
documentation! Without that, it is just proprietary crap.

best regards
Matthias