lkml.org 
[lkml]   [2004]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] kernel sysfs events layer
    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
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:2.672 / U:0.464 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site