lkml.org 
[lkml]   [2005]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    SubjectRe: Input sysbsystema and hotplug
    Date
    On Monday 13 June 2005 17:15, Greg KH wrote:
    > On Mon, Jun 13, 2005 at 05:05:29PM -0500, Dmitry Torokhov wrote:
    > > On Monday 13 June 2005 16:58, Dmitry Torokhov wrote:
    > > > On Monday 13 June 2005 16:26, Kay Sievers wrote:
    > > > > On Mon, Jun 13, 2005 at 04:07:51PM -0500, Dmitry Torokhov wrote:
    > > > > > I am trying to convert input systsem to play nicely with sysfs and I am
    > > > > > having trouble with hotplug agent. The old hotplug mechanism was using
    > > > > > "input" as agent/subsystem name, unfortunately I can't simply use "input"
    > > > > > class because when Greg added class_simple support to input handlers
    > > > > > (evdev, mousedev, joydev, etc) he used that name. So currently stock
    > > > > > kernel gets 2 types of hotplug events (from input core and from input
    > > > > > handlers) with completely different arguments processed by the same
    > > > > > input agent.
    > > > > >
    > > > > > So I guess my question is: is there anyone who uses hotplug events
    > > > > > for input interface devices (as in mouseX, eventX) as opposed to
    > > > > > parent input devices (inputX).
    > > > >
    > > > > Hmm, udev uses it. But, who needs device nodes. :)
    > > > >
    > > >
    > > > Oh, OK. Damn, Andrew will hate us for breaking mouse support yet again :(
    > > > because there are people (like me) relying on hotplug to load input handlers.
    > > > First time I booted by new input hotplug kernel I lost my mouse.
    > > >
    > > > I wonder should we hack something allowing overriding subsystem name
    > > > so we could keep the same hotplug agent? Or should we bite teh bullet and
    > > > change it?
    > > >
    > >
    > > Any chance we could quickly agree on a new name for hander devices (other
    > > than "input") and roll out updated udev before the changes get into the
    > > kernel? For some reason it feels like udev is mmuch quicker moving than
    > > hotplug...
    >
    > I can roll another hotplug release any time you want, there's nothing
    > holding that back.
    >
    > But please, don't break old users of hotplug or udev. Especially
    > hotplug (for udev one can argue that it's still so new that upgrading is
    > realistic, but try to prevent that too...) as that package is so tightly
    > tied to the distro, the next time it would be upgraded is for the next
    > distro release.
    >
    > So, any way to not break anything?
    >

    We could allow classes override what is being transmitted as SUBSYSTEM=
    in hotplug call. If you accept something like the patch below we can keep
    status quo.

    --
    Dmitry

    Subject: allow classes specify subsystem name for hotplug

    Driver core: allow classes specify subsystem name to use in
    hotplug call instead of always using their sysfs
    name.

    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    ---

    drivers/base/class.c | 4 +++-
    include/linux/device.h | 1 +
    2 files changed, 4 insertions(+), 1 deletion(-)

    Index: work/drivers/base/class.c
    ===================================================================
    --- work.orig/drivers/base/class.c
    +++ work/drivers/base/class.c
    @@ -268,8 +268,10 @@ static int class_hotplug_filter(struct k
    static char *class_hotplug_name(struct kset *kset, struct kobject *kobj)
    {
    struct class_device *class_dev = to_class_dev(kobj);
    + struct class *class = class_dev->class;

    - return class_dev->class->name;
    + return class->hotplug_name ?
    + class->hotplug_name(class_dev) : class->name;
    }

    static int class_hotplug(struct kset *kset, struct kobject *kobj, char **envp,
    Index: work/include/linux/device.h
    ===================================================================
    --- work.orig/include/linux/device.h
    +++ work/include/linux/device.h
    @@ -153,6 +153,7 @@ struct class {
    struct class_attribute * class_attrs;
    struct class_device_attribute * class_dev_attrs;

    + char * (*hotplug_name)(struct class_device *dev);
    int (*hotplug)(struct class_device *dev, char **envp,
    int num_envp, char *buffer, int buffer_size);

    -
    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-06-14 08:11    [W:0.037 / U:0.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site