[lkml]   [2005]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/8] Nesting class_device patches that actually work
    On Saturday 15 October 2005 10:08, Kay Sievers wrote:
    > On Fri, Oct 14, 2005 at 12:02:30PM -0500, Dmitry Torokhov wrote:
    > >
    > > 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.
    > > 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.

    We could also add links in the form of:

    /sys/class/<subsystem>/<nested_class> ->

    to keep compatibility with nested classes too to give userspace
    a chance to catch up...

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


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


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

    Call it "subsystem" actually.

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

    No, not at all. The input0 will get a new interface, blahdevX, exactly
    like eventX, mouseX, jsX, tsX, etc. and it will go into "interfaces".
    input0 itself will stay in /sys/class/input/devices.

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

    Yes, I agree that we should have device tree in /sys/devices. But I do not
    think that flat classification is sufficient. Right now it is not enough
    and we compensate for it with names.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-10-17 07:45    [W:0.025 / U:94.820 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site