Re: [patch] kernel sysfs events layer

Kay Sievers
2004-09-05T12:18:13Z

On Sat, Sep 04, 2004 at 10:58:08PM -0400, Robert Love wrote:
> On Sat, 2004-09-04 at 02:54 +0200, Greg KH wrote:
>
> > So, we're back to the original issue. Why is this kernel event system
> > different from the hotplug system? I would argue there isn't one,
> > becides the transport, as you seem to want everything that we currently
> > provide in the current kobject_hotplug() call.
> >
> > But transports are important, I agree.
> >
> > How about you just add the ability to send hotplug calls across netlink?
> > Make it so the kobject_hotplug() function does both the exec() call, and
> > a netlink call (based on a config option for those people who like to
> > configure such stuff.)
>
> This smells.
>
> Look, I agree that unifying the two ideas and transports as much as
> possible is the right way to proceed. But the fact is, as you said,
> transports _are_ important. And simply always sending out a hotplug
> event _and_ a netlink event is silly and superfluous. We need to make
> up our minds.
>
> I don't think anyone argues that netlink makes sense for these low
> priority asynchronous events.
>
> I'd prefer to integrate the two approaches as much as possible, but keep
> the two transports separate. Use hotplug for hotplug events as we do
> now and use kevent, which is over netlink, for the new events we want to
> add.
>
> Maybe always do the kevent from the hotplug, but definitely do not do
> the hotplug from all kevents. It is redundant and extra overhead.
>
> Doing both simultaneous begs the question of why have both. Picking the
> right tool for the job is, well, the right tool for the job.

Yes, it doesn't make much sense to pipe the kevents through
/sbin/hotplug, but I definitely want the hotplug-events over netlink,
to get rid of the SEQNUM reorder nightmare and unpredictable delay of
the execution of the /etc/hotplug.d/ helpers, we currently can't handle
very well with HAL.

I expect, that we need to have both transports (for hotplug), cause early
boot is unable to react to netlink messages.
The /sbin/hotplug can easily switched off, after some "advanced event daemon"
is running by: "echo -n "" > /proc/sys/kernel/hotplug".

What about moving the /sbin/hotplug execution from lib/kobject.c to
kernel/kobj_notify.c and merge it with our netlink code? This would
separate the "object-storage" from the "object-notification" which is
nice. And we would have a single place to implement all kind of event
transports.
If anybody invents some other kind of transport it can go into
kobj_notify.c. All transports can share some code and are highly
configurable then.

kernel/kobj_notify.c would export:
kobject_hotplug(const char *action, struct kobject *kobj)
kobj_notify (const char *signal, struct kobject *kobj, struct attribute *attr)

lib/kobject.c just calls kobject_hotplug() and we get the event on both
transports at the same time. All other events just use kobj_notify() which
doesn't do /sbin/hotplug.

How does it sound?

Thanks,
Kay