In message <199812220956.BAA10201@shell17.ba.best.com>  Todd Whitesel wrote:
> This refers to a thread from last month :)
> 


> > To the kernel, the interface would probably be via registration of
> > callbacks.
> 
> Hmm, would kernel threads make it more attractive to have an "input queue"
> for each event receiver, and the receiver simply blocks on the queue? Are
> kernel threads likely to become standard or is there value in keeping them
> optional?

If you have a callback you can wakeup your thread. I've your bound to 
thread you have to wait for it to be scheduled, always.
Callbacks please ...

> 
> I personally do not trust callbacks/signals very much. I prefer it if they
> are either (a) "pure" and totally re-entrant, (b) set a global flag and
> return, or (c) throw an exception (e.g. longjmp). There is a reason UNIX
> shells are the grossest programs in the world: they actually do everything
> you have to do if you want to handle signals robustly.

> 
> > Via the interface, one could register for interest in certain kinds of 
> 
> Like:
>     - the stat() data for this inode has changed.
>     - the stat() data of anything under this inode has changed. (expensive?)
>     - mode sense data(?) for this device has changed. (disk insert/remove)
>     - umm... just map everything into the file system and use the first two?
> 
> > events, and then get notification (via messages arriving on the file
> > descriptor or via the callbacks) of all the sorts of events we're
> > worrying about.
> 
> Right. I was wondering, what's the "overflow" behavior like? I don't think
> we want to allow denial-of-service attacks that flood the event system. One
> of two things must be true: event sources must be capable of blocking as
> pipe-writers currently do when the pipe fills; or event sources must be able
> to 'merge' events in some well-defined way, so that a finite queue size is
> preserved yet no vital information is lost.

As the source may be a kernel activity (eg. interrupt) you can't block. 
The only thing you can block is syntetic events from another userlevel program.

> 
> Example: if APM writes multiple sleep, wake, sleep, wake sequences to a
> process that is blocked on something unrelated like a network socket, we
> don't want the event queue to slowly back up and choke kmem, nor do we
> want APM to block! So we could define some interfaces as mailboxes of
> sticky bits, such as "system as slept at least once since last event"
> and "system has woken at least once since last event".

What you need is a way to modify/delete an existing event. It is than
up to the event-generator to remove obsoletet messages. There should also 
be a maximum of active/allocated events and the error handling should
be done by the event-generator again.

> 
> > One requirement I think we need for APM events is that the notified
> > parties must have the chance to finish their work before APM goes to
> > sleep.  I don't particularly care if that's by calling synchronously, or
> > waiting for a thread delivering the notification to exit, or something
> 
> It would be nice if we could do something like guaranteeing all event
> receivers at least N cycles of user CPU time to respond to the signal,
> and within that time root can do anything (even delay or cancel the action)
> but non-root can only ask for a single finite extension (bounded by a
> sysctl limit). This is actually getting kind of complicated, but I think
> it's because the APM case is more than just event delivery, it's careful
> negotiation before systemwide actions occur.

Which can be handled by the APM code. Sleeping should be done at a high
priority to make sure the event gets delivered fast.

> 
> > Of course, for user-level applications there should be some timeout
> > beyond which the APM code says "screw you" and transitions to the next
> > power state anyway.
> 
> Right, although user programs that wait on the network could potentially get
> screwed through no fault of their own. I'm betting this is a Hard Problem,
> so there is only so much we can do about it, except teach app writers to be
> more careful. The difference between this and shutdown/halt is that when the
> user opens his laptop back up, he expects everything to still be there. But
> if he's telnetting via cell-modem or something, this might be a little tricky.

The site he telneted to, may have dropped the line by than anyway, you
may have a new dhcp address etc.
(BTW we need a kernel interface for events too, eg. PCMCIA needs to know
 if the system did a sleep/wakeup to figure scan for removed/added cards).

BTW.
Most commercial system that have an event interface into the filesystem
(for HSM use) have one process talking to the kernel and all other 
interested partys talk to that process via a unix-domain  or loopback
socket.
This allows some filtering to avoid waking up many proccesses for 
every event.

Stefan
> 
> Todd Whitesel
> toddpw @ best.com

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---