>>> [...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
> 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?

Probably, yes, seeing as how this is port-sparc.  The /dev/kd that I
mentioned later that paragraph was not, I think, on a SPARC (I think it
must have been on the sun3 port), and I also think wscons is not really
"there" enough to take over yet.

>> 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*?

If wscons is supported on your hardware, yes. :-)

> 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.

To a certain extent this is true.  Not all ports do this, and those
that do don't all do it to the same degree or under the same
circumstances.  Since this is port-sparc, and I know a little something
about SPARCs, I can perhaps say a bit more. :-)

When the kernel first starts, it uses ROM callbacks for console input
and output.  Once the console device is attached, though, it switches
over to using its own drivers - with one exception: if the console is a
framebuffer for which NetBSD has no console driver.  In that case,
output is still done through the ROM callbacks.  (Input is not a
problem.  SPARC keyboards vary much less than SPARC framebuffers, and I
believe all console input devices are supported directly by the kernel.)

The ROM callbacks will still be used even if the device is supported in
some circumstances, such as when ddb has control after a panic
(assuming things are set for ddb to get control upon a panic, of
course).  But they are sufficiently unusual circumstances that they
don't really affect this discussion in practice.

>> 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)

The one machine that I flip between headed and headless, I don't run a
getty on ttya, just console.  That's how I deal with that issue.
(Effective, but not much help to you.)

> 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?

"Yes."  Each view has some truth, depending.  For our purposes here,
there are really two cases: framebuffer supported directly by NetBSD
for output, and framebuffer *not* so supported.  (If RASTERCONSOLE is
not configured in, all framebuffers are treated as unsupported in this
respect.)  In all cases, I believe NetBSD does its own input handling,
but output goes through ROM callbacks in the "unsupported" cases.
However, since it affects only output, this distinction doesn't matter
here: you can still do /dev/kd (or /dev/fbconsole or whatever you want
to call it); it's just a question of whether framebuffer text output is
generated by poking at video RAM or by calling a ROM callback.  The
only case where this may cause trouble is if you have a keyboard and
framebuffer, but console is set to serial anyway, and you want to talk
to /dev/fbconsole.  In the `unsupported framebuffer' case, this is
probably not possible, and /dev/fbconsole would have to not work.

The ROMs are sometimes used for other things, too, such as mapping the
kernel into all possible MMU contexts at boot, but they don't affect
this discussion.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B