Re: UNIX kernel notification system

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Wed, 5 Oct 2011 07:18:50 +0000
David Holland <dholland-tech%netbsd.org@localhost> wrote:

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

I agree that this is not the way to go; however I think that messages
could have more structure without necessarily being only an enumeration
(and the code to human-print them for the debugger or higher-level
processes could be part of the kernel services, although custom
formatters may be wanted for GUI applications, perhaps).
Unfortunately, this would probably also require at least some minimal
dynamic tagged-typed system (string, number, address/pointer,
condition-type, print-function, etc) so it has its own
complexity, without mentioning how to gracefully memory-manage
these objects...  There is proplist, but it seems overkill with
unnecessary parsing overhead.

If wanting to be minimal, why would a simple category integer
enumeration be a problem?  There would be much fewer categories than
message types, and the category could help to determine at which level
to route the message.  If I understand, this is what Erik had in mind?
A libc function could also easily map a category integer to a
human-readable uppercase string for debugging and syslog.

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

I think that this would be a good approach; it also reminds me
of dbus, although I'm not particularily a fan of its implementation
(it also embeds Rexx-like facilities for registering services and RPC,
something I find redundant on unix, and the broadcasting model has
security implications).

Assuming we had such a userspace message router, kernel messages would
also be tagged with the category, uid, pid, lwp (and possibly -1 where
one of those isn't applicable)?

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

The category enum I was talking about earlier could also be called a
channel, I guess
-- 
Matt