Linus Torvalds wrote:
> This still isn't a global serialization thing, though. For example,
> there's no reason _another_ device should be serialized with the disk
> discovery.
Yes, that sounds a lot better. Let's hope nobody discovers such
a reason ...
> An easy way to do partial serialization is something like this:
That would work. It's in fact a per-class message queue, in which
sleeping processes play the role of messages ;-)
I thought a bit about what else one could do with this interface:
- if you need loss/error handling, and are willing to keep one
bit of information for each such class in the kernel, the it
could register whether processing the previous event has
succeeded, i.e. whether the kernel was able to launch a helper,
and whether that helper has returned with exit status 0. This
bit could be returned by the synchronization call.
- in principle it would now be easy, and in many ways cleaner and
more efficient, to turn this into a per-class event demon, with
a "real" event queue. The problem is that you'd probably still
want classes that are not serialized, and the kernel wouldn't
know whether a given class needs serialization before
/sbin/hotplug has run for a while. Neiter configuring class
behaviour nor adding an "asychronous class" look particularly
attractive to me.
Too bad. A synchronous /sbin/hotplug as follows would certainly
be nice, e.g. assuming that in each class only one event type
can occur:
#!/bin/sh
agent=$1
read event
set $event
<... normal /sbin/hotplug code ...>
or, the high-performance variant:
#!/bin/sh
exec /etc/hotplug/$1.agent
#!/bin/sh
<... do really expensive initialization ...>
while read event; do
set $event
<... normal /etc/hotplug/*.agent code ...>
done
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:31 EST