Greetings and Sublimations!

>> I want to attach a serial terminal to ttya that I can use as the
>> console from time to time.  [...]
>> There are other times when I want to be able to attach a
>> monitor/keyboard and use *that* as the "console".
>> [...conflict over the "console" settings in ttys...]
>
>The right fix to this, I believe, is to have something like
>/dev/fbconsole and run getty on both ttya and fbconsole, but _not_ on

Hmmm... looking under /dev I guess you're talking about an
*imaginary* fbconsole device.  I.e. a *future* fix, not
something I can implement currently?

>console.  I have a fairly clear memory that some NetBSD rev on some
>hardware had /dev/kd which was essentially this fbconsole thing; I
>don't remember what NetBSD version or what port, though.  I believe
>that with the general tendency to move everything to wscons, you will
>get /dev/ttyE0 as your fbconsole device and the problem will therefore
>go away.


But will it *really*?   Without having poked through the sources,
I confess to be showing my ignorance.  But, from other behaviours
I have observed, it *seems* that the "boot rom" (or some portion
of it) is retained and built upon within NetBSD.  I.e. the
OS depends upon it instead of supplanting it.

So, is the interface to "console" buried *within* this piece
of code?  I.e. does the boot rom (firmware) do the remapping
of ttya to "console" when it fails to detect the keyboard?
If so, implementing an "fbconsole" (assuming it only
handles the *video* aspects) still leaves the keyboard
input at the mercy of the boot monitor.

(grrr... too early in the day -- am I making myself clear?)

>In the meantime, I have no good solution.  I have fairly few machines
>that flip between headed and headless, and I generally deal with them
>by setting things by hand once logged in.


Yes, that would deal with the $TERM issue easily enough.
But, wouldn't handle the problem of two getty's trying to
run on ttya in the headless case  (the getty spawned on ttya
and the getty on "console" which has been remapped to ttya)

>> And, since ttyb can't (?) serve as the console, there is no way to
>> use it to solve the problem (??)
>
>I think it can, for most machines.  "setenv input-device ttyb" and
>"setenv output-device ttyb" would be my guesses, but it depends on your
>ROM rev.  Check "printenv" output; the variable names are usually
>pretty clear.  (If your ROM rev is so old it doesn't have "printenv",
>I'm not sure what to do.  Sun-3s have a q command in the monitor and a
>defined structure of values in NVRAM, but I don't know how much of that
>is true of old SPARCs.)


Yes, but I don't think that really works around the problem *if*
the firmware is handling things.  I think it just changes all
of the previous ttya/console comments to ttyb/console -- i.e. it
just *moves* the problem to a diferent connector but doesn't
*change* the nature of the problem (??)

Could someone please clarify the role the firmware plays
in a system once NetBSD has booted?  Is it treated as a
"hardware abstraction layer" of sorts?  Or, is its role
simply one of convenience?

Thx,
--don