------- Blind-Carbon-Copy

To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
in-reply-to: <199811191959.OAA18475@ginger.cmf.nrl.navy.mil>
To: tech-kern@netbsd.org
Subject: New IDE control program & changed to apmd
Date: Thu, 19 Nov 1998 14:11:57 -0800
From: Jonathan Stone <jonathan@Cuisinart.Stanford.EDU>

[followups probably to tech-kern; bcc'ed to current-users]


>If you have questions or comments, please let me know.

Hi Ken,

This is clearly useful and I'm glad to see it in the tree.

But i've had some experience with handling similar issues under
Linux. One thing i learnt is that calling out to specific scripts just
does not scale very well.

I think a better answer (something netbsd strives for, right?)  is a
generalized event-notification mechanism, plus a *protocol* for
sending events:

   a) from the kerenl to userland, in response to hardware events.
   b) from userland to the kernel, in response to user requests.

For instance, i'd really like to see APM integrated with PCMCIA so
that one can, for instance, configure PCMCIA NICs to go into ``sleep
mode'' (or poweroff) if you go onto battery power, and powering them
up if you go onto mains power.  And  similar tricks if you have a
multi-homed laptop.

To suppor that, I'd like to see a generalized `protocol' for encoding
events: preferably in binary. I'd encode the source, a general 'class"
(say, apm vs pcmcia vs external (ups) `powerfail imminent' vs big-iron
``machine check''), a class-specific event identifier (e.g., pcmcia
card insertion vs removal), and some further encoding for more
specific info (like pcmcia device tuples).

Perhaps one day, if we support lkm device-drivers for general
devices, notification of newly-attached devices (for which a driver was
just loaded) would happen this way, too.  For PCI and other buses,
not just PCMCIA.

Im agnostic on string vs binary encodings: the key issue is a
hierarchical encoding so we can add new messages, yet still get them
routed to all the user-space handlers that may be interested.

Anyway, thanks for adding this: it definitel fills a need.  But I'd
_really_ like to see this evolve to a more general notification
mechanism that can better tie together specific events from different
sources into a unified handling scheme.

------- End of Blind-Carbon-Copy