Re: [patch 0/8] Nesting class_device patches that actually work

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, Oct 14, 2005 at 10:45:54AM +0200, Kay Sievers wrote:
> On Thu, Oct 13, 2005 at 04:35:25PM -0500, Dmitry Torokhov wrote:
> > On 10/13/05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > >
> > > 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:
> > >
> > 
> > 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.
> 
> > 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.

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