Nesting class_device patches that actually work

Ok, finally. Here's a set of _working_ patches that properly implement nesting class_device structures, and the follow-on patches to move the input subsystem to use them. Hotplug and release functions work properly now, and this will let us move /sys/block/ to use class and class_device structures soon.

Quoted 5 lines · Greg KH

Ok, finally. Here's a set of _working_ patches that properly implement nesting class_device structures, and the follow-on patches to move the input subsystem to use them. Hotplug and release functions work properly now, and this will let us move /sys/block/ to use class and class_device structures soon.

Oh, Kay, do you have a public patch to udevstart/udev that can handle this nested structure? It might be good to have that so people can test these in the next -mm.

Ok, finally. Here's a set of _working_ patches that properly implement nesting class_device structures, and the follow-on patches to move the input subsystem to use them. Hotplug and release functions work properly now, and this will let us move /sys/block/ to use class and class_device structures soon.

The input patches are on top of almost all of Dmitry's input patches. All of them are together in one series in my public patches at:
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
and should show up in the next -mm release.

The sysfs tree looks the same as it did last time, but now hotplug works properly for addition and removal, and we actually free the memory used :)

For those that don't remember, here's the sysfs tree on my desktop:

$ tree /sys/class/input/ -d
/sys/class/input/
|-- input0
|   |-- capabilities
|   |-- event0
|   `-- id
|-- input1
|   |-- capabilities
|   |-- device -> ../../../devices/platform/i8042/serio1
|   |-- event1
|   |   `-- device -> ../../../../devices/platform/i8042/serio1
|   `-- id
|-- input3
|   |-- capabilities
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- event2
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- id
|   |-- mouse0
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   `-- ts0
|       `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
`-- mice

Ok, I think that covers everything.

Oh, one final thing. I really don't think that input should be a class. It looks like a "bus" and acts like a "bus" (you have different devices that have different drivers bind to them, and you want to load those drivers with the hotplug mechanism.)

The only thing keeping this from
being a bus is the fact that we can't bind multiple drivers to a single device these days, and I can't see a way to move this code to that model, so oh well...

Quoted 5 lines · Greg KH

Oh, one final thing. I really don't think that input should be a class. It looks like a "bus" and acts like a "bus" (you have different devices that have different drivers bind to them, and you want to load those drivers with the hotplug mechanism.)

[ Vojtech mumbles something about saying that from the beginning. ]

Quoted 4 lines

The only thing keeping this from
being a bus is the fact that we can't bind multiple drivers to a single device these days, and I can't see a way to move this code to that model, so oh well...

Ok, finally. Here's a set of _working_ patches that properly implement nesting class_device structures, and the follow-on patches to move the input subsystem to use them. Hotplug and release functions work properly now, and this will let us move /sys/block/ to use class and class_device structures soon.

The input patches are on top of almost all of Dmitry's input patches. All of them are together in one series in my public patches at:
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
and should show up in the next -mm release.

The sysfs tree looks the same as it did last time, but now hotplug works properly for addition and removal, and we actually free the memory used :)

For those that don't remember, here's the sysfs tree on my desktop:

$ tree /sys/class/input/ -d
/sys/class/input/
|-- input0
|   |-- capabilities
|   |-- event0
|   `-- id
|-- input1
|   |-- capabilities
|   |-- device -> ../../../devices/platform/i8042/serio1
|   |-- event1
|   |   `-- device -> ../../../../devices/platform/i8042/serio1
|   `-- id
|-- input3
|   |-- capabilities
|   |-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- event2
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   |-- id
|   |-- mouse0
|   |   `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
|   `-- ts0
|       `-- device -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0
`-- mice

To answer the remaining questions from the last thread:

Q: how are you going to determine what is really a class_dev and what
isn't, as there's no way to tell.
A: Who cares?

Seriously, tools like udev will watch for the "dev" file to be able create the required device node, and it will be the one getting the hotplug event. attribute groups do not generate hotplug events, and you should not be having a file called "dev" in your attribute group anyway.

Q: why does event2, mouse0, and input3 in the above tree all have the
same "device" symlink?
A: userspace tools expect that symlink there. They do not know that if
you traverse up a directory, and look at the symlink there, that's what the subdirectory points to too. That would be a mess. And, as those different class_device structures really are all bound to that same struct device, that is the proper representation of this.

Q: How can you determine between input interfaces and input devices?
A: input devices have a "dev" file. And what really does userspace need
to know here?

Q: Wait, what about nesting struct class instead? That would work,
right?
A: No, nesting classes is not going to happen. Classes are "major"
things, and aren't related to each other (well, some are by their

name only, like the different "scsi*" classes, but to the user, they are separate.)
Also, we can't emulate /sys/block with nested classes. And no, we can't change this to be /sys/class/block/partitions and /sys/class/block/devices without almost every sysfs user complaining loudly. That's not the real representation of the devices, and we need to really try to keep backward compatibility where we possibly can.

Ok, I think that covers everything.

Oh, one final thing. I really don't think that input should be a class. It looks like a "bus" and acts like a "bus" (you have different devices that have different drivers bind to them, and you want to load those drivers with the hotplug mechanism.) The only thing keeping this from being a bus is the fact that we can't bind multiple drivers to a single device these days, and I can't see a way to move this code to that model, so oh well...

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 1 line

Quoted 6 lines

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

Quoted 1 line

Hi,

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes. I recenty got an e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!
We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Quoted 81 lines · Kay Sievers

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!
We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

Quoted 6 lines

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Sorry, my previous drawing wasn't correct for the input devices.

Here is a new picture of the:
- all classes are unique and flat and will stay the same, even when the hierarchy of the devices changes
- all hierarchy is _only_ in /sys/devices
- virtual and physical devices are both in /sys/devices
proposal.

/sys

|-- class
|   |-- block
|   |   `-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda
|   |-- block_partition
|   |   |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda1
|   |   `-- sda2 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda2
|   |-- pci
|   |   `-- 0000:00:1f.2 -> ../../devices/pci0000:00/0000:00:1f.2
|   |-- input
|   |   |-- mice -> ../../devices/mice
|   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
|   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
|   |-- input_device
|   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
|   `-- tty
|       `-- console -> ../../devices/console
|
|
|-- devices
|   |-- pci0000:00
|   |   `-- 0000:00:1f.2
|   |       |-- class -> ../../../class/pci
|   |       |-- config
|   |       |-- device
|   |       |-- host0
|   |       |   `-- target0:0:0
|   |       |       |-- 0:0:0:0
|   |       |       |   |-- sda
|   |       |       |   |   |-- dev
|   |       |       |   |   |-- range
|   |       |       |   |   |-- removable
|   |       |       |   |   |-- sda1
|   |       |       |   |   |   |-- dev
|   |       |       |   |   |   |-- size
|   |       |       |   |   |   |-- start
|   |       |       |   |   |   `-- stat
|   |       |       |   |   |-- sda2
|   |       |       |   |   |   |-- dev
|   |       |       |   |   |   |-- size
|   |       |       |   |   |   |-- start
|   |       |       |   |   |   `-- stat
|   |       |       |   |   |-- size
|   |       |       |   |    `-- stat
|   |       |       |   |-- model
|   |       |       |   |-- type
|   |       |       |   `-- vendor
|   |       |       `-- power
|   |       |           `-- state
|   |       |-- modalias
|   |       |-- resource
|   |       |-- subsystem_device
|   |       |-- subsystem_vendor
|   |       `-- vendor
|   |-- platform
|   |   `-- i8042
|   |       `-- serio0
|   |            `-- input0
|   |                 |-- event0
|   |                 |   `-- dev
|   |                 |-- mouse0
|   |                 |   `-- dev
|   |                 |-- bind_mode
|   |                 |-- description
|   |                 |-- id
|   |                 |   |-- extra
|   |                 |   |-- id
|   |                 |   |-- proto
|   |                 |   `-- type
|   |                 |-- modalias
|   |                 |-- protocol
|   |                 |-- rate
|   |                 |-- resetafter
|   |                 `-- resolution
|   |-- mice
|   |   `-- dev

...

Thanks,
Kay

Quoted 174 lines · Kay Sievers

Quoted 81 lines · Kay Sievers

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!
We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

Quoted 6 lines

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Sorry, my previous drawing wasn't correct for the input devices.

Here is a new picture of the:
- all classes are unique and flat and will stay the same, even when the hierarchy of the devices changes
- all hierarchy is _only_ in /sys/devices
- virtual and physical devices are both in /sys/devices
proposal.

/sys

|-- class
|   |-- block
|   |   `-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda
|   |-- block_partition
|   |   |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda1
|   |   `-- sda2 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda2
|   |-- pci
|   |   `-- 0000:00:1f.2 -> ../../devices/pci0000:00/0000:00:1f.2
|   |-- input
|   |   |-- mice -> ../../devices/mice
|   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
|   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
|   |-- input_device
|   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
|   `-- tty
|       `-- console -> ../../devices/console
|
|
|-- devices
|   |-- pci0000:00
|   |   `-- 0000:00:1f.2
|   |       |-- class -> ../../../class/pci
|   |       |-- config
|   |       |-- device
|   |       |-- host0
|   |       |   `-- target0:0:0
|   |       |       |-- 0:0:0:0
|   |       |       |   |-- sda
|   |       |       |   |   |-- dev
|   |       |       |   |   |-- range
|   |       |       |   |   |-- removable
|   |       |       |   |   |-- sda1
|   |       |       |   |   |   |-- dev
|   |       |       |   |   |   |-- size
|   |       |       |   |   |   |-- start
|   |       |       |   |   |   `-- stat
|   |       |       |   |   |-- sda2
|   |       |       |   |   |   |-- dev
|   |       |       |   |   |   |-- size
|   |       |       |   |   |   |-- start
|   |       |       |   |   |   `-- stat
|   |       |       |   |   |-- size
|   |       |       |   |    `-- stat
|   |       |       |   |-- model
|   |       |       |   |-- type
|   |       |       |   `-- vendor
|   |       |       `-- power
|   |       |           `-- state
|   |       |-- modalias
|   |       |-- resource
|   |       |-- subsystem_device
|   |       |-- subsystem_vendor
|   |       `-- vendor
|   |-- platform
|   |   `-- i8042
|   |       `-- serio0
|   |            `-- input0
|   |                 |-- event0
|   |                 |   `-- dev
|   |                 |-- mouse0
|   |                 |   `-- dev
|   |                 |-- bind_mode
|   |                 |-- description
|   |                 |-- id
|   |                 |   |-- extra
|   |                 |   |-- id
|   |                 |   |-- proto
|   |                 |   `-- type
|   |                 |-- modalias
|   |                 |-- protocol
|   |                 |-- rate
|   |                 |-- resetafter
|   |                 `-- resolution
|   |-- mice
|   |   `-- dev

Quoted 4 lines

...

Thanks,
Kay

I have a great deal of bad experience attempting to perform emergency mounts on Sun Workstations that have this same general scheme of un-typable:

../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sda/sda1

People need to enter this stuff without the help of cut-and-pase or even a back-space that works. Are you trying to replace "/dev/sda1" with the monster above? If so, you have way too much time on your hands.

Sorry, my previous drawing wasn't correct for the input devices.

Here is a new picture of the:
- all classes are unique and flat and will stay the same, even when the hierarchy of the devices changes
- all hierarchy is _only_ in /sys/devices
- virtual and physical devices are both in /sys/devices
proposal.

/sys

|-- class
|   |-- mouse
|   |   |-- mice -> ../../devices/mice
|   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
|   |---event
|   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
|   |-- input
|   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
|   `-- tty
|       `-- console -> ../../devices/console

/sys

|-- class
|   |-- input
|   |   |-- mice -> ../../devices/mice
|   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
|   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
|   |-- input_device
|   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
|
|-- devices
|   |-- platform
|   |   `-- i8042
|   |       `-- serio0
|   |            `-- input0
|   |                 |-- event0
|   |                 |   `-- dev
|   |                 |-- mouse0
|   |                 |   `-- dev
|   |                 |-- bind_mode
|   |                 |-- description
|   |                 |-- id
|   |                 |   |-- extra
|   |                 |   |-- id
|   |                 |   |-- proto

|   |                 |   `-- type
|   |                 |-- modalias
|   |                 |-- protocol
|   |                 |-- rate
|   |                 |-- resetafter
|   |                 `-- resolution
|   |-- mice
|   |   `-- dev

Quoted 8 lines · Kay Sievers

Sorry, my previous drawing wasn't correct for the input devices.

Here is a new picture of the:
- all classes are unique and flat and will stay the same, even when the hierarchy of the devices changes
- all hierarchy is _only_ in /sys/devices
- virtual and physical devices are both in /sys/devices
proposal.

I like the layout.

I'm not completely sure whether mouse0 and event0 are the same class, because they have different APIs and protocols. And I believe that class is exactly that - a collection of devices where you can use the same API to access them. A possibility would be to do it like this:

Quoted 11 lines

/sys

|-- class
|   |-- mouse
|   |   |-- mice -> ../../devices/mice
|   |   |-- mouse0 -> ../../devices/platform/i8042/serio0/input0/mouse0
|   |---event
|   |   `-- event0 -> ../../devices/platform/i8042/serio0/input0/event0
|   |-- input
|   |   `-- input0 -> ../../devices/platform/i8042/serio0/input0
|   `-- tty
|       `-- console -> ../../devices/console

It might be too much work to create a new class in each of the handlers, it'd be similar to harddrives and partititions having different classes.

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!

We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Quoted 54 lines · Kay Sievers

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

Quoted 4 lines

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

Does anyone know how many of these we have?

We are moving /sys/block
to /sys/class so many of these will require upgrades anyway.

Could libsysfs hide some of the changes?

Btw, is your proposal with moving it all into /sys/device less drastic?

Quoted 3 lines

It invents artificial subclass names below a "master" class, which is absolutely not needed.

I really do not see why you think that "ieee1394_node" and "ieee1394_transport" are natural names while "ieee1394/node" and "ieee1394/transport" are "artificial".

Quoted 3 lines

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

Why is "interfaces" is more magic than "wireless"? Is it just the name that is confusing? We could call it "netifs", "netdevs", "devices" - just pick a name you like better.

Quoted 5 lines

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

Quoted 4 lines

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

Well, it is rather simple I think - if it works with hardware and needs power management then it's a physical device.

If it just a
kernel abstraction/API for group of similar objects then it is a class device. Physical device can only have one driver, class device can have several interfaces/views. So far we have input interfaces and SCSI generic interface.

Quoted 3 lines

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!

Could you tell me which ones you consider virtual buses?

Quoted 5 lines

We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

Quoted 7 lines

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Having hierarchy in the /sys/devices is nice and I think I agree with it. I don't think it will reslve any confusion for the coder WRT physical/virtual devices - after all I think you just need to change class_device kset from class's to devices and that will "move" the object into the new spot in /sys tree.

However having class hierarchy spelled out is also nice because it _does exist_. Right now we just encode it with common prefixes in the class names.

Quoted 2 lines · Dmitry Torokhov

Does anyone know how many of these we have?

A lot! From general distro specific system-management to subsystem specific setup tools and tons of udev rules... There is definitely no chance to break /sys/class in _all_ subsystems by introducing subdirectories.

Quoted 2 lines

We are moving /sys/block
to /sys/class so many of these will require upgrades anyway.

If needed, there can be a link from /sys/block to /sys/class/block and it will look exactly like is is today.

Quoted 1 line

Could libsysfs hide some of the changes?

Not without hardcoding susbsystem-specific knowledge/translation into it, which will not happen and will be definitely the wrong way to solve such a thing. Only the block-move case could be easily covered by libsysfs as it is already prepared to do this and "block" is a "class" from the first version of libsysfs on.

Quoted 1 line

Btw, is your proposal with moving it all into /sys/device less drastic?

Definitely, cause it keeps all the curent api! The only difference is that class-devices are reached by symlinks instead of real directories. The pathes to the devices are the same!

Quoted 4 lines

Quoted 3 lines

It invents artificial subclass names below a "master" class, which is absolutely not needed.

Quoted 3 lines

I really do not see why you think that "ieee1394_node" and "ieee1394_transport" are natural names while "ieee1394/node" and "ieee1394/transport" are "artificial".

Well, all three classes are different kind of devices. All devices are at the same level, which I absolutely like. You propose an artificial "hierarchy of classes" or a "superclass", which will break everything and give us no advantage, I think.

Quoted 7 lines

Quoted 3 lines

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

Why is "interfaces" is more magic than "wireless"? Is it just the name that is confusing? We could call it "netifs", "netdevs", "devices" - just pick a name you like better.

Cause "interfaces" is a classification by itself and this is wrong! If you give one of your "subclass devices" an interface, let's say "input0" will get a device node to talk to the low-level device, where do you want to stick it then? You will move the device around to the "interface" directory? That breaks the api!

Take a step back and look what a kernel interface is about. It is to give userland a unified view to devices. The internal kernel structure like "bus", "class", "bus_device", "class_device" are in no way interesting for userspace. It's a kernel implementation detail.

All we want are DEVICES! And from devices we want:
- a classification: /sys/class/<name>
- the properties: attribute files to read values or to invoke actions
- the dependency tree: /sys/devices/<device1>/<device2>
Any mix between any of the three things is completely wrong, makes it hard to read and can never provide a stable device interface.

A lot! From general distro specific system-management to subsystem specific setup tools and tons of udev rules... There is definitely no chance to break /sys/class in _all_ subsystems by introducing subdirectories.

Quoted 1 line

Btw, is your proposal with moving it all into /sys/device less drastic?

Definitely, cause it keeps all the curent api! The only difference is that class-devices are reached by symlinks instead of real directories. The pathes to the devices are the same!

So, what to do now? Here's my proposal for the future.

We figure out some way to agree on the input stuff, using class_device and get that into 2.6.15. Personally, I like the stuff I just did and is in the -mm tree :)

Quoted 6 lines · Greg KH

So, what to do now? Here's my proposal for the future.

We figure out some way to agree on the input stuff, using class_device and get that into 2.6.15. Personally, I like the stuff I just did and is in the -mm tree :)

If we are shooting at 2.6.15 I would just go with original 2-class solution (input and input_dev) with doing symlinks in form of /sys/class/input/mouseX/device -> /sys/class/input_dev/inputX

Correct me if I am wrong but this is least invasive and (at least for older hotplug installations) all that is needed to make it work is a symlink from input.agent to input_dev.agent.

--
Dmitry

Quoted 8 lines · Dmitry Torokhov

Quoted 6 lines · Greg KH

So, what to do now? Here's my proposal for the future.

We figure out some way to agree on the input stuff, using class_device and get that into 2.6.15. Personally, I like the stuff I just did and is in the -mm tree :)

Quoted 7 lines

If we are shooting at 2.6.15 I would just go with original 2-class solution (input and input_dev) with doing symlinks in form of /sys/class/input/mouseX/device -> /sys/class/input_dev/inputX

Correct me if I am wrong but this is least invasive and (at least for older hotplug installations) all that is needed to make it work is a symlink from input.agent to input_dev.agent.

I'm not sure if we want to introduce an incorrect change to the sysfs topology only to remove it in the next release. Currently, class devices are not expected to link between one another.

Quoted 3 lines · Kay Sievers

A lot! From general distro specific system-management to subsystem specific setup tools and tons of udev rules... There is definitely no chance to break /sys/class in _all_ subsystems by introducing subdirectories.

I agree.

Quoted 5 lines

Quoted 1 line

Btw, is your proposal with moving it all into /sys/device less drastic?

Definitely, cause it keeps all the curent api! The only difference is that class-devices are reached by symlinks instead of real directories. The pathes to the devices are the same!

Ok, I've spent a while thinking about this proposal and originally I thought it was the same thing we had heard years ago. But I was wrong, moving the class stuff into the device tree is the right thing to do, as long as we keep them as new "things" in the tree (previous proposals just had the /sys/class stuff as symlinks pointing to the devices themselves, which would not work for a range of reasons.)

So, what to do now? Here's my proposal for the future.

We figure out some way to agree on the input stuff, using class_device and get that into 2.6.15. Personally, I like the stuff I just did and is in the -mm tree :)

But, if you think we can't break userspace by adding nested class devices just yet, I agree, and can probably just put a symlink in /sys/class/input to the nested devices, which will make everything "just work". I'll try that out later tonight and let you all know how it goes.

Then, we move the class stuff into real devices. There was always a lot of duplication with the class and device code, and this shows that there is a commonality there. At the same time, I'll work on making the attribute stuff easier and possibly merge the kobject and device structures together a bit (possibly I said, I don't know quite how much yet...)

But this second step is going to take a while, have to not break everything along the way, and should hopefully clean up a lot of mess tht the current driver core has. I'd be glad to do it :)

Acceptable to everyone?

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

Quoted 32 lines · Greg KH

Quoted 3 lines · Kay Sievers

A lot! From general distro specific system-management to subsystem specific setup tools and tons of udev rules... There is definitely no chance to break /sys/class in _all_ subsystems by introducing subdirectories.

I agree.

Quoted 5 lines

Quoted 1 line

Btw, is your proposal with moving it all into /sys/device less drastic?

Definitely, cause it keeps all the curent api! The only difference is that class-devices are reached by symlinks instead of real directories. The pathes to the devices are the same!

Ok, I've spent a while thinking about this proposal and originally I thought it was the same thing we had heard years ago. But I was wrong, moving the class stuff into the device tree is the right thing to do, as long as we keep them as new "things" in the tree (previous proposals just had the /sys/class stuff as symlinks pointing to the devices themselves, which would not work for a range of reasons.)

So, what to do now? Here's my proposal for the future.

We figure out some way to agree on the input stuff, using class_device and get that into 2.6.15. Personally, I like the stuff I just did and is in the -mm tree :)

But, if you think we can't break userspace by adding nested class devices just yet, I agree, and can probably just put a symlink in /sys/class/input to the nested devices, which will make everything "just work". I'll try that out later tonight and let you all know how it goes.

Quoted 6 lines

Then, we move the class stuff into real devices. There was always a lot of duplication with the class and device code, and this shows that there is a commonality there. At the same time, I'll work on making the attribute stuff easier and possibly merge the kobject and device structures together a bit (possibly I said, I don't know quite how much yet...)

Quoted 5 lines

But this second step is going to take a while, have to not break everything along the way, and should hopefully clean up a lot of mess tht the current driver core has. I'd be glad to do it :)

Acceptable to everyone?

Sounds good to me. The changes to driver model internals may be substantial.

For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

It also may make sense to move bus_types to the "class" interface. The layered classes suggestion is especially useful here because we can have a "hardware" or "bus" class that acts as a parent for "pci", "usb", etc.

Also, we could make driver objects a "class" and represent them in the global device tree, giving each driver instance its own unique namespace.

Quoted 5 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree. If the device doesn't have any parents or dependencies, then that's logically where it belongs.

Sounds good to me. The changes to driver model internals may be substantial. For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

It also may make sense to move bus_types to the "class" interface. The layered classes suggestion is especially useful here because we can have a "hardware" or "bus" class that acts as a parent for "pci", "usb", etc.

Also, we could make driver objects a "class" and represent them in the global device tree, giving each driver instance its own unique namespace.

Quoted 4 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree.

If the device doesn't have any parents or dependencies, then that's logically where it belongs.

Quoted 7 lines · Adam Belay

Sounds good to me. The changes to driver model internals may be substantial. For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

That's a bus, not a class device. Drivers bind to devices through a bus. That's why we have busses.

Quoted 3 lines

Also, we could make driver objects a "class" and represent them in the global device tree, giving each driver instance its own unique namespace.

Huh? How would you do that? Also, we really don't have different driver "instances", so trying to represent something like that in sysfs would probably be more work than it's worth.

Quoted 6 lines

Quoted 5 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

Quoted 3 lines

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree.

Everything that's currently a platform device go to the root? No, that's not going to happen, sorry.

Quoted 3 lines

If the device doesn't have any parents or dependencies, then that's logically where it belongs.

We do have a real platform "bus" that devices hang off of. Where else is that keyboard controller at :)

As stated above, the keyboard actually does have a real location to hang off of. Nonetheless, a keyboard controller is a physical device. It's very different from a "virtual device" like a tty. Therefore, it seems unreasonable to make virtual devices belong to the "platform" bus.

If a device doesn't have a parent device, it belongs at the root of the tree. That's the only obvious way to represent such a lack of dependency. This applies to both class and physical devices.

Quoted 11 lines · Greg KH

Quoted 7 lines · Adam Belay

Sounds good to me. The changes to driver model internals may be substantial. For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

That's a bus, not a class device. Drivers bind to devices through a bus. That's why we have busses.

If class devices and devices belong in the same tree, then clearly the original distinction is artificial. "struct bus_type" is a class of "struct device". "struct class" is a class of "struct class_dev". We now know of devices in between these two extremes (e.g. pci express port driver). It's also possible that drivers will want to bind to class devices (e.g. a partition driver binding to a block device). Isn't it fair to say that the "bus_type" vs. "class" distinction is also artificial? At the very least they are duplicating some code.

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree.

Everything that's currently a platform device go to the root? No, that's not going to happen, sorry.

Quoted 13 lines · Adam Belay

Quoted 11 lines · Greg KH

Quoted 7 lines · Adam Belay

Sounds good to me. The changes to driver model internals may be substantial. For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

That's a bus, not a class device. Drivers bind to devices through a bus. That's why we have busses.

Quoted 8 lines

If class devices and devices belong in the same tree, then clearly the original distinction is artificial. "struct bus_type" is a class of "struct device". "struct class" is a class of "struct class_dev". We now know of devices in between these two extremes (e.g. pci express port driver). It's also possible that drivers will want to bind to class devices (e.g. a partition driver binding to a block device). Isn't it fair to say that the "bus_type" vs. "class" distinction is also artificial? At the very least they are duplicating some code.

I agree and would like to see the "bus" functionality just as set of special methods of a unified device struture also used for class devices.

Quoted 11 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree.

Everything that's currently a platform device go to the root? No, that's not going to happen, sorry.

But will sticking stuff like "mice" or "tty" into "platform" will really work? These devices belong to their own primary class like "input" or "tty" and they can not be part of a "bus" at the same time, right?

I'm dreaming of:
- merging "struct device" and "struct class_device"

- provide current "bus" and "class" methodes for _all_ devices

Quoted 9 lines · Greg KH

Quoted 7 lines · Adam Belay

Sounds good to me. The changes to driver model internals may be substantial. For example, because buses and classes will share more code, it's reasonable to allow drivers to bind to any "device" object, even class devices. Of course this would be limited to classes that choose to implement driver matching etc. We are doing this now with the pci express port driver.

Quoted 2 lines

That's a bus, not a class device. Drivers bind to devices through a bus. That's why we have busses.

If class devices and devices belong in the same tree, then clearly the original distinction is artificial. "struct bus_type" is a class of "struct device".

"struct class" is a class of "struct class_dev". We now know of devices in between these two extremes (e.g. pci express port driver).

It's also possible that drivers will want to bind to class devices (e.g. a partition driver binding to a block device).

Isn't it fair to say that the "bus_type" vs. "class" distinction is also artificial? At the very least they are duplicating some code.

Quoted 6 lines

Quoted 2 lines

Also, we could make driver objects a "class" and represent them in the global device tree, giving each driver instance its own unique namespace.

Huh? How would you do that? Also, we really don't have different driver "instances", so trying to represent something like that in sysfs would probably be more work than it's worth.

(all in same tree)
pci0000:00.00 <- physical device
|
\- e1000:0 <- driver
|
\- eth0 <- class device

We already informally have driver instances. They're pointed to in "driver_data".

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

Oh, one tiny problem. "virtual devices" are not currently represented in our device tree, but are in the class tree. Things like the different vc and ttys and misc devices are examples of this. I'll just put them on the "platform" bus if no one minds.

I think we should be trying to kill off the platform bus (it's artifical and doesn't show the real relationships between these devices). Instead, just hang them off the root of the tree.

Quoted 2 lines

Everything that's currently a platform device go to the root? No, that's not going to happen, sorry.

Not at all. Rather, everything that's currently a platform device goes to where it actually belongs in the device tree. ACPI (and other firmware) enumerates all of these devices. They're generally children of LPCs and ISA bridges.

Making a special exception for these devices is ugly when we can easily represent them like every other device. This will even be possible without ACPI for many of these devices if we create an "ISA" bus driver abstraction.

The main point here is that "platform" is really a hack to represent primitive physical devices that don't fit well into the driver model. There may be better ways of approaching this problem.

Quoted 5 lines

Quoted 2 lines

If the device doesn't have any parents or dependencies, then that's logically where it belongs.

We do have a real platform "bus" that devices hang off of. Where else is that keyboard controller at :)

As stated above, the keyboard actually does have a real location to hang off of. Nonetheless, a keyboard controller is a physical device. It's very different from a "virtual device" like a tty. Therefore, it seems unreasonable to make virtual devices belong to the "platform" bus.

If a device doesn't have a parent device, it belongs at the root of the tree. That's the only obvious way to represent such a lack of dependency. This applies to both class and physical devices.

But, if you think we can't break userspace by adding nested class devices just yet, I agree, and can probably just put a symlink in /sys/class/input to the nested devices, which will make everything "just work". I'll try that out later tonight and let you all know how it goes.

Quoted 5 lines · Greg KH

But, if you think we can't break userspace by adding nested class devices just yet, I agree, and can probably just put a symlink in /sys/class/input to the nested devices, which will make everything "just work". I'll try that out later tonight and let you all know how it goes.

Below is a patch that does this for the event portion of input. Good news is that the symlink shows up just fine in sysfs. Bad news is that even with your previously posted patch, udev dies a horrible death.

And udev dies today with the nested stuff too, so that's not good either.

Quoted 11 lines · Greg KH

Quoted 5 lines · Greg KH

But, if you think we can't break userspace by adding nested class devices just yet, I agree, and can probably just put a symlink in /sys/class/input to the nested devices, which will make everything "just work". I'll try that out later tonight and let you all know how it goes.

Below is a patch that does this for the event portion of input. Good news is that the symlink shows up just fine in sysfs. Bad news is that even with your previously posted patch, udev dies a horrible death.

Quoted 2 lines

And udev dies today with the nested stuff too, so that's not good either.

Nevermind, that was due to the kernel oops, not udev.

Kay, your original udev patch works just fine. What I don't see is why the existing udev release doesn't also work, now that I have the symlinks set up. I'll try to figure that one out too...

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs! We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree! That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

Quoted 32 lines · Dmitry Torokhov

Quoted 23 lines · Kay Sievers

The nesting classes implement a fraction of a device hierarchy in /sys/class. It moves arbitrary relation information into the class directory, where nothing else than device classification belongs. What is the rationale behind sticking device trees into class?

Instead of that, I propose a unification of "/sys/devices-devices" and "class-devices". The differentiation of both does not make sense in a wold where we can't really tell if a device is hardware or virtual.

We should model _all_ devices with its actual realationship in /sys/devices and /sys/class should only be a pinter to the actual devices in that place. Device like "mice", which have no parent, would sit at the top level of /sys/devices. All devices in /sys/class are only symlinks and never devices by itself.
That way userspace can read all device relation at _one_ place in a sane way, and we keep the clean class interface to have easy access to all devices of a specific group.
It gives us the right abstraction and is future proof, cause the class interface will not change when the relation between devices changes. The destinction between classes and buses would no longer be needed, and as we see in the "input" case never made sense anyway.

Quoted 7 lines

/sys/class/block would look exactly like /sys/block today. The only difference is that there are symlinks to follow instead of class devices on its own. With every device creation we will get the whole dependency path of the device in the DEVPATH and a "classsification symlink" in /sys/class. The input devices are all clearly modeled in its hierarchy, in /sys/devices but we also get clean class interfaces:

Quoted 8 lines

Kay eased my task by enumerating all issues I have with Greg's approach. Not all the world is udev and not all class devices have "/dev" represetation so haveing one program being able to understand new sysfs hierarchy is not enough IHMO.

However I do not think that "moving" class devices into /sys/devices hierarchy is the right solution either because one physical device could easily end up belonging to several classes.

Sure, than that physical (while that distinction is silly by itself) will just have several child devices. Look at the mouse0 and event0 in the ascii drawing.

Quoted 7 lines

I recenty got an
e-mail from Adam Belay (whom I am pulling into the discussion) regarding his desire to rearrange net/wireless representation. I think it would be quite natural to have /sys/class/net/interfaces and /sys/class/net/wireless /sys/class/net/irda, and /sys/class/net/wired subclasses where "interfaces" would enumerate _all_ network interfaces in the system, and the rest would show only devices of their class.

That solution would keep a better device separation, sure. But it is completely incompatible with everything we ever had in sysfs and nobody wants to rewrite _all_ userspace programs.

It invents artificial subclass names below a "master" class, which is absolutely not needed.

It creates the magic "interfaces" directory, which is confusing, cause it classifies devices by itself.

It doesn't represent any relationship and hierarchy of devices and adding a forest of magic symlinks and "device" pointers is a very bad design. The proposed "inter-class" symlinks make it even harder to understand sysfs as it already is.

The biggest problem with current sysfs is that the driver hacker has to decide if the device is "hardware" or "virtual" which in a lot of cases just can't tell and this distiction doesn't make any sense today.

All the more complex subsystems use "virtual buses" and an unconnected bunch of class-devices to model its sysfs represention, which is just to work around a major design flaw in sysfs!

We really should get _one_ device tree with its natural hierarchy, get rid of the stupid "device"-link, the PHYSDEVPATH and the unconnected class devices. Every device should just carry its dependency tree in it _own_ devpath!

I'm very sure, we want a unified tree in /sys/devices, regardless of the type of device, to represent the global hierarchy wich is exactly what you want to know from a device tree!
That way we stack "virtual" _and_ "physical" in a sane manner and at the same time get very clean class interfaces. We would stop to mix up "hierarchy" and "classes" all over the tree.

NACK. The whole point of classes is to have common attributes and behaviours over a set of devices. There's much more than the dev attribute to them. Please just fix the input code to get their semantics right instead.