[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: UNIX kernel notification system
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
> 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
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?
Main Index |
Thread Index |