Re: Registrar-Based Notification Mechanism

[SNIP-SNIP-SNIP]

> 1) Subscription/unsubscription for notifications: This is a bit ugly,
> since the functions for that live in libroot and the primary target 
> for
> the request is the registrar. Either the request is passed through a 
> port
> directly to the registrar, or it travels into the kernel and goes the 
> same
> way the to the registrar the notifications take (i.e. through the 
> shared
> memory). Once there, the listener is added to the appropriate
> list/hashtable/...

Since, as you mentioned elsewhere, sub/unsub requests are not 
particularly time sensitive, I think I prefer the latter suggested 
method (syscall into kernel then back out through the ring buffer). I 
guess the port method could avoid requiring changes to the kernel to 
add sub/unsub for a new set of notifications, but you'll need to make 
changes anyway to actually implement said notifications, so you 
wouldn't really be gaining anything.

[MORE SNIP]

> Mmh, that's it, I think. At least my mind feels a bit emptier now. ;-)

That all sounds very reasonable and well-thought-out from where I'm 
standing. Any thoughts from kerneland? I hadn't thought about it much 
before, but I really like the idea of having a common notification 
system like this.

-Tyler