Re: UNIX kernel notification system

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Oct 03, 2011 at 12:40:46AM -0700, Erik Fair wrote:
 > 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.

Trying to enumerate all possible kernel messages and assign code
numbers to them, so that they're machine readable, is a lost cause and
also probably a bad idea. I've used systems that tried to do that.
What happens is that (1) when you really want it (e.g., system is
hosed, running single user, etc.) the daemon that's supposed to read
the message codes and print them out in human-readable form isn't
running, or dies, or gets behind and drops information/loses data, so
you end up having to read the raw codes and translate them with the
(paper) reference manual in hand. Enough of this and you don't need
the manual any more, but that's not a state anyone wants to aspire to.

Then, (2) the number of possible messages is enormous and there's a
huge pressure to not add more or change them around (for compatibility
reasons) so a lot of the messages will not contain much more real
information than "something went wrong". Cf. <errno.h>. And also (3)
many messages are parameterized, e.g. device errors will come with a
device name and unit number. This creates a large pile of prosaic but
real typechecking issues. There are projects (e.g. compilers) where
enumerating all possible messages as codes is vaguely feasible, if
you're willing to put a lot of effort into it; for kernels I think
it's completely unfeasible.

As for receiving messages, as I think I've said from time to time
before the right way to do this is to have a per-user process that
connects to the message source and displays messages as they come in.
This is true not just for kernel messages but also other random stuff
that gets blatted to ttys: urgent syslogs, shutdown walls, biff
notices, talk requests, etc. If there's no receiver process, writing
to the tty is the fallback state; but remember that a desktop (let
alone a phone) may have no ttys open even when the user is working
away and willing to receive messages.

As I've also said from time to time, there really ought to be a
system-level publish/subscribe system for carrying such messages; to
really get such messages right you need to have multiple channels and
the ability to filter or subscribe selectively or wahtever. Such a
service can be used for other things too.

This is not to say that there can't and shouldn't be machine-readable
kernel messages too. We already have kqueue, for example. Some measure
of unification among the various things that currently exist would
probably be desirable... but the publish/subscribe service would (or
could anyway) cover a lot of that.

As for kernel messages of the form

   ,------------------------.
   |  Please insert volume  |
   |     Workbench_1.3      |
   |      in any drive      |
   |  [OK]        [Cancel]  |
   '------------------------`

which are what usually brings up this topic, that's a special case of
machine-readable kernel messages with prepaid reply. If you want to
receive such notices because you're logged in on the desktop... you
run the (or a) receiver tool. If you don't, they bounce and whatever
triggered the notice fails. This is something the Amiga got wrong; if
you were trying to run a BBS or something unattended, and one of these
popped up, the whole system (more or less) would hang until you came
along and clicked on it. So you could get programs to detect them and
automatically "click" Cancel, but that's the wrong approach.

The hard part is making certain things able to trigger user notices
(and thereby block in the kernel waiting for userland) without
deadlocking out the wazoo.

-- 
David A. Holland
dholland%netbsd.org@localhost