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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/