Consoles, past and future.

[Marcel Moolenaar]

On Sep 2, 2005, at 12:39 AM, Poul-Henning Kamp wrote:

>     1. Kernel boot progress indicator.
>     All the device probe and attach etc.
>     API: printf(9) and friends.
>
>     2. Single user terminal connection
>     For manually fixing things before /etc/rc is run.
>     API: Any tty(4) (and various other) devices will do.
>
>     3. System initialization progress indicator.
>     The output from /etc/rc and its spawn.
>     API: any file, pipe, stream socket and most devices will do.
>          Using a tty(4) gives the ability to SIGINT processes which
>          hang/sleep/get confused during startup.

2 & 3 are in essence the same thing currently. That is, both depend  
on the
tty device /sbin/init uses. Whether they should be the same thing or not
is not expressed with this statement.

> gdb(9) has its own hooks into the device driver.  I'm not sure I
> know why, but it probably makes sense.

Because a debug port is not a tty. The communication over a debug port
is not bound to the rules and regulations of a tty. It therefore demands
a separate interface. That you can implement one in terms of the other
is merely an upshot.

If we want to think radically, we probably should shift our thinking.
We still treat the console as a central and fundamental piece of the
kernel. I think we should instead make a 180 degrees turn and start
off with a kernel that's deaf and dumb. I think it goes without saying
that such an OS is still functional.

Now, with this flatscreen or CRT in front of us, it would be nice to
actually make use of it. But for what I hear you think... What is the
use of a display? Well, it's a feedback device. We interact with the
machine by looking at the display and act on what we see. This also
means that the use of a display is dictated by the the abilities of
the user, the role the machines plays in the user's life and the role
of thew user in relation to the machine.

In concreto: We have end-users, sysadmins, developers and machine
builders as our possible audience and related to that we have FreeBSD
ranging from a home computer to a hardware validation vehicle.

The feedback appropriate in each of those scenarios is different.
If we have disabled users, a display may not even be usable as a
feedback device in the first place...

What this means is that printf(9) can never mean the same as printf(3).
It makes more sense to have printf(9) be the interface to internal
logging and use a completely separate mechanism for sending the log
information to some device if such would be beneficial. This allows
us to not display the boot probe gobbledegook so that we can present
the end-user with a nice logo instead as well as allows us do the
complete opposite and and make all those weird developers happy.

In any case, this concept cannot be explained in an email that's
written on the verge of me going to work, so let me end here and
see what grows from the seed that has been planted.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net