Re: Input sysbsystema and hotplug

Re: Input sysbsystema and hotplug

[Kay Sievers]

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. :)

> If not then I could rename Greg's class
> to "input_dev" and my new class to "input" and that will be compatible
> with older installations. 

I still think we should rename the parent-input device class and keep
the more interesting class named "input", cause this will not break current
setups besides one hotplug-handler and follows the usual style in sysfs.

> Also, in the long run I would probably want to see something like this:
> 
> /sys/class/input---input0
> 		 |
> 		 |-input1
> 		 |
> 		 |-input2
> 		 |
> 		 |-mouse---mouse0
> 		 |	 |
> 		 |	 |-mouse1
> 		 |	 |
> 		 |	 --mice
> 		 |
> 		 |-event---event0
> 			 |
> 			 |-event1
> 			 |
> 			 |-event2
> 
> where inputX are class devices, mouse and event are subclasses of input
> class and mouseX and eventX are again class devices.

We don't support childs of class devices until now. Would be nice maybe, but
someone needs to add that to the driver-core first and we would need to make
a bunch of userspace stuff aware of it ...

Kay

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Monday 13 June 2005 16:26, Kay Sievers wrote:
> On Mon, Jun 13, 2005 at 04:07:51PM -0500, Dmitry Torokhov wrote:
> > 
> > where inputX are class devices, mouse and event are subclasses of input
> > class and mouseX and eventX are again class devices.
> 
> We don't support childs of class devices until now. Would be nice maybe, but
> someone needs to add that to the driver-core first and we would need to make
> a bunch of userspace stuff aware of it ...
> 

Something like patch below will suffice I think (not tested).

-- 
Dmitry

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

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

Index: work/drivers/base/class.c
===================================================================
--- work.orig/drivers/base/class.c
+++ work/drivers/base/class.c
@@ -145,7 +145,10 @@ int class_register(struct class * cls)
 	if (error)
 		return error;
 
-	subsys_set_kset(cls, class_subsys);
+	if (cls->parent)
+		subsys_set_kset(cls, cls->parent->subsys);
+	else
+		subsys_set_kset(cls, class_subsys);
 
 	error = subsystem_register(&cls->subsys);
 	if (!error) {
Index: work/include/linux/device.h
===================================================================
--- work.orig/include/linux/device.h
+++ work/include/linux/device.h
@@ -145,6 +145,7 @@ struct class {
 	char			* name;
 
 	struct subsystem	subsys;
+	struct class		* parent;
 	struct list_head	children;
 	struct list_head	interfaces;
 	struct semaphore	sem;	/* locks both the children and interfaces lists */

Re: Input sysbsystema and hotplug

[Greg KH]

On Mon, Jun 13, 2005 at 04:38:08PM -0500, 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:
> > > 
> > > where inputX are class devices, mouse and event are subclasses of input
> > > class and mouseX and eventX are again class devices.
> > 
> > We don't support childs of class devices until now. Would be nice maybe, but
> > someone needs to add that to the driver-core first and we would need to make
> > a bunch of userspace stuff aware of it ...
> > 
> 
> Something like patch below will suffice I think (not tested).

No, you need to increment the parent when you register the child.  Look
at the device code for what's needed for this.

thanks,

greg k-h

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Monday 13 June 2005 17:17, Greg KH wrote:
> On Mon, Jun 13, 2005 at 04:38:08PM -0500, 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:
> > > > 
> > > > where inputX are class devices, mouse and event are subclasses of input
> > > > class and mouseX and eventX are again class devices.
> > > 
> > > We don't support childs of class devices until now. Would be nice maybe, but
> > > someone needs to add that to the driver-core first and we would need to make
> > > a bunch of userspace stuff aware of it ...
> > > 
> > 
> > Something like patch below will suffice I think (not tested).
> 
> No, you need to increment the parent when you register the child.  Look
> at the device code for what's needed for this.
>

Don't quite follow what you are saying. If you are saying that it needs
to call class_get(parent) I don't think it's necessary as kobject code
will grab the reference (to class's subsystem kset).

All in all it seems to be working:

[dtor@core ~]$ ls /sys/class/input_dev/
input0  input3  input4  input_dev_subclass
[dtor@core ~]$

-- 
Dmitry

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

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?

Adding Andrew to CC... 

> > If not then I could rename Greg's class
> > to "input_dev" and my new class to "input" and that will be compatible
> > with older installations. 
> 
> I still think we should rename the parent-input device class and keep
> the more interesting class named "input", cause this will not break current
> setups besides one hotplug-handler and follows the usual style in sysfs.

-- 
Dmitry

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

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...

-- 
Dmitry

Re: Input sysbsystema and hotplug

[Greg KH]

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?

thanks,

greg k-h

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

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);
 

Re: Input sysbsystema and hotplug

[Kay Sievers]

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...

Hmm, not sure. It is not udev itself, it's the rule set which is
different on every distro and not really in our control. The hotplug agent
is just one symlink if you want a quick & dirty fix.

Kay

Re: Input sysbsystema and hotplug

[Hannes Reinecke]

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...
> 
My original patch used 'input_device' for it.
Would be nice if it could stay.
This way we have the following event sequence:

input_device event (contains all attributes like 'abs', 'ev' etc.)
-> triggers loading of any input modules
   -> creates the proper input devices
input event (contains the 'dev' attribute for udev)

As the main point of the original 'input' event is in fact the device
node creation (we only have max 4 input modules, which isn't that hard
to figure out), I'd vote for keeping the name 'input' for the device
event and use a new event type 'input_device' for the class device.

And yes, we should break compability and come up with a clean
implementation. And as the original input event is an abomination I
don't see the point in keeping compability with a broken interface.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Tuesday 14 June 2005 02:32, Hannes Reinecke wrote:
> And yes, we should break compability and come up with a clean
> implementation.

But those pesky users scream every time we break their mice ;)

> And as the original input event is an abomination I 
> don't see the point in keeping compability with a broken interface.
>

Why is it abomination (aside from using old mechanism to call
hotplug)? It looks like it transmits all data necessary to load
appropriate input handler...

-- 
Dmitry

Re: Input sysbsystema and hotplug

[Hannes Reinecke]

Dmitry Torokhov wrote:
> On Tuesday 14 June 2005 02:32, Hannes Reinecke wrote:
>>And yes, we should break compability and come up with a clean
>>implementation.
> 
> But those pesky users scream every time we break their mice ;)
> 
>>And as the original input event is an abomination I 
>>don't see the point in keeping compability with a broken interface.
>>
> 
> Why is it abomination (aside from using old mechanism to call
> hotplug)? It looks like it transmits all data necessary to load
> appropriate input handler...
> 
Because there are _two_ events with the name 'input'.
Both run under the same name but carry different information.
One is required to load the module and the other is required to create
the device node.

That's what I call an abomination.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Tuesday 14 June 2005 02:47, Hannes Reinecke wrote:
> Dmitry Torokhov wrote:
> > On Tuesday 14 June 2005 02:32, Hannes Reinecke wrote:
> >>And yes, we should break compability and come up with a clean
> >>implementation.
> > 
> > But those pesky users scream every time we break their mice ;)
> > 
> >>And as the original input event is an abomination I 
> >>don't see the point in keeping compability with a broken interface.
> >>
> > 
> > Why is it abomination (aside from using old mechanism to call
> > hotplug)? It looks like it transmits all data necessary to load
> > appropriate input handler...
> > 
> Because there are _two_ events with the name 'input'.
> Both run under the same name but carry different information.
> One is required to load the module and the other is required to create
> the device node.
> 
> That's what I call an abomination.
>

Ah, I see. Yep, it "input" wasn't reused when input_handlers were converted
to class_simple we probably would not have this discussion now.

-- 
Dmitry

Re: Input sysbsystema and hotplug

[David Brownell]

On Tuesday 14 June 2005 12:47 am, Hannes Reinecke wrote:
> 
> Because there are _two_ events with the name 'input'.
> Both run under the same name but carry different information.
> One is required to load the module and the other is required to create
> the device node.
> 
> That's what I call an abomination.

Or at least messy, though it's been true forever that all the
event classes have included multiple events.   USB hotplug has
aided both "interface" and "device" driver match policies since
before 2.4.0, for example.  I guess "input" has seemed simpler,
partially because it started later and slimmer.


Maybe starting with the next kernel or so, distros should be
starting to avoid these issues by converting to slim versions
of the /sbin/hotplug script, handling the two steps separately.

First the driver loading ... for USB, PCI/Cardbus, and PCMCIA
this usually suffices:

    if [ "$ACTION" = "add" -a -n "$MODALIAS" -a ! -L $DEVPATH/driver ]
    then
        modprobe -q $MODALIAS
    fi

Then (otherwise?) the device node creation

    if [ -n "$DEVPATH" ]
    then
        /sbin/udevsend $1
    fi

And don't have any /etc/hotplug or /etc/hotplug.d scripts.
(There'd still need to be an /etc/init.d/coldplug to make
up for hotplug events that preceded viable userspace.)

One problem with that is that not all subsystems yet support
the new $MODALIAS (and /sys/devices/.../modalias) stuff, and
of course "input" is one subsystem that doesn't.

That support shifts the "what module to load" logic from
hotplug scripts (slow and no-longer-appropriate) over to
module-init-tools (3.2 and newer for the PCMCIA support).

- Dave

Re: Input sysbsystema and hotplug

[Greg KH]

On Mon, Jun 13, 2005 at 04:07:51PM -0500, Dmitry Torokhov wrote:
> Hi,
> 
> 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.

Why not?  What's wrong with using the existing input class?  I was
hopeing it would get flushed out into something "real" someday.  All you
have to do is keep the "dev" stuff in there somewhere and udev will be
happy.

> /sys/class/input---input0
> 		 |
> 		 |-input1
> 		 |
> 		 |-input2
> 		 |
> 		 |-mouse---mouse0
> 		 |	 |
> 		 |	 |-mouse1
> 		 |	 |
> 		 |	 --mice
> 		 |
> 		 |-event---event0
> 			 |
> 			 |-event1
> 			 |
> 			 |-event2
> 
> where inputX are class devices, mouse and event are subclasses of input
> class and mouseX and eventX are again class devices.

Yes, lots of people want class devices to have children.  Unfortunatly
they don't provide patches with their requests :)

thanks,

greg k-h

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Monday 13 June 2005 17:16, Greg KH wrote:
> On Mon, Jun 13, 2005 at 04:07:51PM -0500, Dmitry Torokhov wrote:
> > Hi,
> > 
> > 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.
> 
> Why not?  What's wrong with using the existing input class?  I was
> hopeing it would get flushed out into something "real" someday.  All you
> have to do is keep the "dev" stuff in there somewhere and udev will be
> happy.
> 

They are different. Your input class represents userpsace interfaces, my
input class represent middleman class devices. If you remember, input
core looks like this:
                                     evdev (/dev/input/eventX devices)
				    /
    hardware			   /
    device	-------- input_dev - mousedev (/dev/input/mouseX,
    (serio port,		   \           /dev/input/mice
     USB port)			    \
                                      joydev (/dev/input/jsX devices)

Your input class is fine (except for its name as it uses the same name
that input core was/is using for notification about new instances of
input_devs), but it represents different point in object hierarchy, as
it represents /dev/input/{mouse|event|js}X objects.

Your class devices are useful to properly create device nodes and
probably set up userspace applications to use new input devices. My
input_dev class devices are useful so hotplug would load proper input
handlers (joysdev, mousedev) to create your class devices.

I hope it explains things a bit...
       
-- 
Dmitry

Re: Input sysbsystema and hotplug

[Jon Smirl]

On 6/13/05, Greg KH <gregkh@suse.de> wrote:
> > where inputX are class devices, mouse and event are subclasses of input
> > class and mouseX and eventX are again class devices.
> 
> Yes, lots of people want class devices to have children.  Unfortunatly
> they don't provide patches with their requests :)

I did, but you didn't like it.

> 
> thanks,
> 
> greg k-h

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Input sysbsystema and hotplug

[Greg KH]

On Tue, Jun 14, 2005 at 02:21:53AM -0400, Jon Smirl wrote:
> On 6/13/05, Greg KH <gregkh@suse.de> wrote:
> > > where inputX are class devices, mouse and event are subclasses of input
> > > class and mouseX and eventX are again class devices.
> > 
> > Yes, lots of people want class devices to have children.  Unfortunatly
> > they don't provide patches with their requests :)
> 
> I did, but you didn't like it.

Heh, yes, sorry, you did.

Hm, I don't even remember why I didn't like it anymore, last I remember,
I think you got the parent reference counting correct, right?  Care to
dig out the patch and send it again?

thanks,

greg k-h

Re: Input sysbsystema and hotplug

[Jon Smirl]

On 6/14/05, Greg KH <gregkh@suse.de> wrote:
> > > Yes, lots of people want class devices to have children.  Unfortunatly
> > > they don't provide patches with their requests :)
> >
> > I did, but you didn't like it.
> 
> Heh, yes, sorry, you did.
> 
> Hm, I don't even remember why I didn't like it anymore, last I remember,
> I think you got the parent reference counting correct, right?  Care to
> dig out the patch and send it again?

Check out the thread "event sequencing" in the hotplug group. 

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Input sysbsystema and hotplug

[Jon Smirl]

On 6/14/05, Greg KH <gregkh@suse.de> wrote:
> Heh, yes, sorry, you did.
> 
> Hm, I don't even remember why I didn't like it anymore, last I remember,
> I think you got the parent reference counting correct, right?  Care to
> dig out the patch and send it again?

I brought this forward from a kernel a couple of months old so it may
need some checking.

diff --git a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -406,8 +406,9 @@ int class_device_add(struct class_device
 
 	/* first, register with generic layer. */
 	kobject_set_name(&class_dev->kobj, "%s", class_dev->class_id);
-	if (parent)
+	if (parent && !class_dev->kobj.parent)
 		class_dev->kobj.parent = &parent->subsys.kset.kobj;
+	class_dev->kobj.parent = kobject_get(class_dev->kobj.parent);
 
 	if ((error = kobject_add(&class_dev->kobj)))
 		goto register_done;
@@ -438,6 +439,12 @@ int class_device_add(struct class_device
 	return error;
 }
 
+int class_device_add_child(struct class_device *class_dev, struct
class_device *parent)
+{
+	class_dev->kobj.parent = &class_dev->kobj;
+	return class_device_add(class_dev);
+}
+
 int class_device_register(struct class_device *class_dev)
 {
 	class_device_initialize(class_dev);
@@ -463,6 +470,7 @@ void class_device_del(struct class_devic
 	class_device_remove_attrs(class_dev);
 
 	kobject_hotplug(&class_dev->kobj, KOBJ_REMOVE);
+	kobject_put(class_dev->kobj.parent);
 	kobject_del(&class_dev->kobj);
 
 	if (parent)
@@ -581,6 +589,7 @@ EXPORT_SYMBOL_GPL(class_device_register)
 EXPORT_SYMBOL_GPL(class_device_unregister);
 EXPORT_SYMBOL_GPL(class_device_initialize);
 EXPORT_SYMBOL_GPL(class_device_add);
+EXPORT_SYMBOL_GPL(class_device_add_child);
 EXPORT_SYMBOL_GPL(class_device_del);
 EXPORT_SYMBOL_GPL(class_device_get);
 EXPORT_SYMBOL_GPL(class_device_put);
diff --git a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -208,6 +208,7 @@ extern int class_device_register(struct 
 extern void class_device_unregister(struct class_device *);
 extern void class_device_initialize(struct class_device *);
 extern int class_device_add(struct class_device *);
+extern int class_device_add_child(struct class_device *, struct
class_device *);
 extern void class_device_del(struct class_device *);
 
 extern int class_device_rename(struct class_device *, char *);



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Tuesday 14 June 2005 10:02, Jon Smirl wrote:
> On 6/14/05, Greg KH <gregkh@suse.de> wrote:
> > Heh, yes, sorry, you did.
> > 
> > Hm, I don't even remember why I didn't like it anymore, last I remember,
> > I think you got the parent reference counting correct, right?  Care to
> > dig out the patch and send it again?
> 
> I brought this forward from a kernel a couple of months old so it may
> need some checking.
>

Ah, this one allows adding subdevices to class devices whereas mine is for
adding subclasses to classes. Both are needed in the long run IMHO.
 
-- 
Dmitry

Re: Input sysbsystema and hotplug

[Hannes Reinecke]

Dmitry Torokhov wrote:
> Hi,
> 
> 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). If not then I could rename Greg's class
> to "input_dev" and my new class to "input" and that will be compatible
> with older installations. 
> 
> Also, in the long run I would probably want to see something like this:
> 
> /sys/class/input---input0
> 		 |
> 		 |-input1
> 		 |
> 		 |-input2
> 		 |
> 		 |-mouse---mouse0
> 		 |	 |
> 		 |	 |-mouse1
> 		 |	 |
> 		 |	 --mice
> 		 |
> 		 |-event---event0
> 			 |
> 			 |-event1
> 			 |
> 			 |-event2
> 
> where inputX are class devices, mouse and event are subclasses of input
> class and mouseX and eventX are again class devices.
> 
> Objections, suggestions, etc? 
> 	 
Hmm. I don't like it very much as it mixes two different types of
devices (class devices and subclasses) into one directory.

I think it's cleaner to have two distinct class device types
(one for input_dev and one for input).

subclasses for the input class devices are a neat idea; but I fear the
hotplug event name will change for each subclass device ('input' will
become eg 'mouse'), so we again have to change all hotplug handlers.
And I don't see an easy solution for that ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

Re: Input sysbsystema and hotplug

[Dmitry Torokhov]

On Tuesday 14 June 2005 02:43, Hannes Reinecke wrote:
> Dmitry Torokhov wrote:
> > 	 
> Hmm. I don't like it very much as it mixes two different types of
> devices (class devices and subclasses) into one directory.
> 

If one could come up with a good name to group inputX under I think
it will be OK. We'd have XXX, mouse, joystick, event, ... as subclasses
and all class_devices will be on level below. OTOH input_devs are parents
for mice, joysticks etc so they might be on the higher level.

> I think it's cleaner to have two distinct class device types
> (one for input_dev and one for input).
> 

I actually detest this practice:

[dtor@core ~]$ ls /sys/class/
firmware     ieee1394       ieee1394_protocol  mem   pci_bus        sound  usb_host
graphics     ieee1394_host  input              misc  pcmcia_socket  tty    vc
i2c-adapter  ieee1394_node  input_dev          net   printer        usb
[dtor@core ~]$

dtor@anvil ~]$ ls /sys/class/
cpuid     i2c-adapter  ieee1394_host      input  msr      printer      sound  usb_host
firmware  i2c-dev      ieee1394_node      mem    net      scsi_device  tty    vc
graphics  ieee1394     ieee1394_protocol  misc   pci_bus  scsi_host    usb    video4linux
[dtor@anvil ~]$

Firewire has 4 classes on the uppper level, I2C, USB, SCSI and Input got
2 each. It would be much nicer IMHO if we merge them into trees of classes
with poarent class actually defining subsystem.  

> subclasses for the input class devices are a neat idea; but I fear the
> hotplug event name will change for each subclass device ('input' will
> become eg 'mouse'), so we again have to change all hotplug handlers.
> And I don't see an easy solution for that ...
>

We could have parent class define agent/subsystem name for all its children.

-- 
Dmitry

Re: Input sysbsystema and hotplug

[Hannes Reinecke]

Dmitry Torokhov wrote:
> On Tuesday 14 June 2005 02:43, Hannes Reinecke wrote:
>>Dmitry Torokhov wrote:
>>>	 
>>Hmm. I don't like it very much as it mixes two different types of
>>devices (class devices and subclasses) into one directory.
>>
> 
> If one could come up with a good name to group inputX under I think
> it will be OK. We'd have XXX, mouse, joystick, event, ... as subclasses
> and all class_devices will be on level below. OTOH input_devs are parents
> for mice, joysticks etc so they might be on the higher level.
> 
>>I think it's cleaner to have two distinct class device types
>>(one for input_dev and one for input).
>>
> 
> I actually detest this practice:
> 
> [dtor@core ~]$ ls /sys/class/
> firmware     ieee1394       ieee1394_protocol  mem   pci_bus        sound  usb_host
> graphics     ieee1394_host  input              misc  pcmcia_socket  tty    vc
> i2c-adapter  ieee1394_node  input_dev          net   printer        usb
> [dtor@core ~]$
> 
> dtor@anvil ~]$ ls /sys/class/
> cpuid     i2c-adapter  ieee1394_host      input  msr      printer      sound  usb_host
> firmware  i2c-dev      ieee1394_node      mem    net      scsi_device  tty    vc
> graphics  ieee1394     ieee1394_protocol  misc   pci_bus  scsi_host    usb    video4linux
> [dtor@anvil ~]$
> 
> Firewire has 4 classes on the uppper level, I2C, USB, SCSI and Input got
> 2 each. It would be much nicer IMHO if we merge them into trees of classes
> with poarent class actually defining subsystem.  
> 
Correct.
And this in indeed a shortcoming of the driver model, as it basically
only knows about classes and devices.
Maybe it's about time to introduce a subsystem?

>>subclasses for the input class devices are a neat idea; but I fear the
>>hotplug event name will change for each subclass device ('input' will
>>become eg 'mouse'), so we again have to change all hotplug handlers.
>>And I don't see an easy solution for that ...
>>
> 
> We could have parent class define agent/subsystem name for all its children.
> 
Hmm.
We probably could.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de