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    [from the cache]
©2003-2011 Jasper Spaans