On Sun, Sep 05, 2004 at 02:18:14PM +0200, Kay Sievers wrote:
> 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.

I tried it! Here is a version that moves kobject_hotplug() event out of the
kobject core to the new "userspace event"-file kernel/kobject_uevent.c.

The /sbin/hotplug message is now just a special kind of userspace notification.
All hotplug messages are also send over netlink, with the whole hotplug
environment attached to the message. It looks like this on the wire:

  recv(3, "add@/class/input/mouse2\0ACTION=add\0DEVPATH=/class/input/mouse2\0SEQNUM=768\0SUBSYSTEM=input\0", 1024, 0) = 90

All other events like the filesystem device claim/release are only sent
through the netlink interface by kobject_uevent().

Thanks,
Kay