Re: UNIX kernel notification system

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

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

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

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