Re: UNIX kernel notification system

[Erik Fair <fair%netbsd.org@localhost>]

On Oct 3, 2011, at 00:56 , Mouse wrote:

> [Do you really mean to use paragraph-length lines?  I'd suggest against
> it; they impair readability significantly, at least for me.  Manually
> rewrapped in the quotes below.]

less(1) (or more(1)) doesn't take care of you? The nice thing about such 
formatting is that the text can be wrapped at relatively arbitrary word 
boundaries, making it more readably displayable on a wider range of display 
widths (e.g. mobile phones, tablets). Just as all the world's not a VAX (cried 
the PDP-11 users), so also is the world rather more than just 80 by 24.


>> There are three basic modes of UNIX use:
> 
>> 1. traditional multi-user timesharing system.  We in NetBSD land
>> still use our systems this way sometimes; cf. ftp.netbsd.org
> 
>> 2. single-user workstation (this includes laptops) and that user
>> works on the "console" (or "graphics device" + "input devices").
> 
>> 3. lights-out server in some dark closet or data center.  Console?
>> Uh, yeah, it's over there, on top of the KVM or serial switch;
>> keyboard's in the drawer.  Be sure to blow the dust off it [...]
> 
> What about embedded?  Anything from a "smartphone" to a beagleboard to
> an Arduino.  Sometimes there's something that smacks a bit of a console
> (eg, the smartphone); sometimes there isn't really, or if there is it's
> connected up for, at best, debugging.  This partakes of each of the
> above in some respects, depending on the details.
> 
> What about machines with multiple keyboard/screen heads, with
> potentially a different user using each one?  (It's not common, but
> it's certainly not impossible or nonexistent or etc.)  Again, some
> aspects of each of the above.

I'd argue that embedded is a degenerate case of "lights-out", but even more 
restricted in that an embedded device generally has one interface to the world, 
and must make all its communications fit within the protocol of that interface 
... whatever it is. The trouble there is that if the protocol has no way to 
express a given message, the kernel can't say it. This turns into a protocol 
translation & semantics problem very quickly, and that class of problems is 
hard. Consoles are easy - they can express anything ... in the character set 
the console can print, and to the limit of the display (be it paper or screen).

Did I just open the i18n can of worms? Let's hold that thought for the moment.

The multi-bottle+keyboard (& possibly mouse, though last we met, there was only 
one of you ...) is arguably the standard multi-user timesharing system set up, 
with a little more complicated "terminal" (from the I/O association front; TTYs 
(serial ports) made that easy, back in the day). BSD made an incremental step 
towards a multi-user kernel notification model ages ago, in that some kernel 
messages were blatted both on the console, *and* on the "controlling tty" of 
the process that had triggered the message ... if such a proximately 
responsible process could be identified from within the kernel (e.g. the one 
that did the last write(2) call for which the kernel could not allocate a 
filesystem disk block), and if that process even *had* a controlling tty 
(daemons generally don't).

Dear me, I said "bottle" - for those of you who may not remember Cathode Ray 
Tubes (CRT) for display (made principally of glass, hence "bottle"), substitute 
"LCD panel" as appropriate. The point is that unless told a priori, the kernel 
doesn't necessarily know which keyboard+mouse is associated with which 
FB/GPU+display in a multi-user workstation setup; that was the genesis of 
NetBSD's wsmux(4) and the ability to separate and associate inputs with 
otherwise apparently separate displays, with the default configuration being 
for single-user workstation (i.e. all inputs go to "console"; this is much more 
common, and culturally obvious to MacOS users (and Windows users? I don't have 
enough experience there to know)).


>> We ought to try and come up with a notification abstraction model
>> that works reasonably well for each use case, and preferably one
>> which permits automated userland software response to various common
>> events.
> 
> Hmm, socket(AF_KMSGS,SOCK_STREAM,0)?  Not that that's the abstraction,
> just one possible way of implementing it.

We see these taxonomically specified interfaces from the kernel all over the 
place: signal(3), errno.h, envsys(4), the routing socket interface. Any 
interface where we expect software response to some kind of information from 
the kernel, as opposed to human interpretation/intervention.

I'm suggesting that we look at all the printfs (or log(9)) the kernel now can 
generate and see if we can create a taxonomy and thus protocol for most of them 
(I'd argue that, for now, debug is right out, and there will be other kernel 
messages that really only a human can respond to; we won't be able to do them 
all, but we shouldn't get hung up on that), which would allow for software 
handling, whether that handling is merely to transmit it to some other system 
(e.g. syslogd(8)), or some other userland application response (e.g. scripted 
as in powerd(8), as appropriate to the type of system UNIX (NetBSD) is being 
used for.

The handling could even be "look up the appropriate language for this message 
to match what the users of this system know how to read", e.g. catgets(3) in 
NLS message catalogs. See? i18n handled! (OK, except for the translation part, 
but I'll put on an MIT X11 hat here and say, "mechanism, not policy!")

What are the apparent general categories of the messages that the kernel wants 
to report when one looks at all of them? What are the general categories of 
responses one might want to make to those categories of messages? Can we design 
an API (or other mechanism) to reasonably express most of them, and open more 
possibilities for software response?

        Erik <fair%netbsd.org@localhost>