>>> Why oh why doen't init spit out a simple little error message the
>>> first time this fails?
>> How?  With nothing in /dev/, how can init print anything?
> Hmmm...  I had for some reason assumed that the kernel could/would
> keep init's STDIO file descriptors opened on the same device it was
> reading and writing to, making it trivial for init to write out error
> messages....
[later in the same message]
> However if it's easier to just pass the kernel's open console file as
> init's stdin/stdout/stderr, that would be my preferred change -- it
> seems far more elegant to me.

As I understand the current interface, it's not so much that kernel
printf() goes to /dev/console via some sort of "kernel's open console
file", as it is that /dev/console provides a user-land hook to the same
mechanism kernel printf() uses.  That is, you have the layering upside
down: /dev/console is layered on top of kernel output, rather than
kernel output being layered on top of /dev/console (or more precisely
the driver underlying /dev/console).

> Is this not how the UNIX SysV kernels start up init?

I have no idea.  I've never touched source to a SysV system and thus
have never gotten my hands dirty enough with one to tell.

>> One could make a case that the kernel should check for /dev/console
>> [...] In fact...expect a PR that does exactly this, soon.

PR kern/2236, in fact.

> Doesn't the kernel already properly hook /dev/console onto whatever
> is specified by the EEPROM?

Well, no, that's the problem.  The driver that underlies a proper
/dev/console entry, yes, that is hooked into whatever device the EEPROM
points to (on ports that have EEPROMs that can indicate what to use for
the console, that is, but this is port-sun3...).

The problem is the mapping from the "/dev/console" pathname to this
driver.

Yes, the kernel could hand-craft an open file descriptor pointing to a
special device vnode with the correct device numbers for process 1.  In
my opinion the only benefit of this would be that init could whine
about a missing /dev/console - enough other stuff will break that you
need to do a lot of hacking before you can run without /dev/console,
and if you have /dev/console then init can open it for whining about
anything else.

> Which reminds me....  What the heck is this /dev/kd stuff the sun3
> port is using now?  Why no just use /dev/console for what it is?

I don't know; I didn't do it.  But it seems reasonable to me as a way
of getting hold of the keyboard/screen "virtual terminal" on a machine
that has them but doesn't have /dev/console pointed there.  (Think
about it.  A headful machine with serial console specified in the
EEPROM...how would you do anything with the keyboard/screen?  You'd
have to do something, like firing up X, that talks to /dev/fb
(/dev/bwtwo, /dev/cgtwo, whatever) and /dev/kbd.)

> not to mention that the kernel debugger seems incapable of hooking on
> to the EEPROM defined console no matter what.

I think the kernel debugger actually uses the PROM's input and output
facilities, and thus should _always_ use the PROM's console device.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu