lkml.org 
[lkml]   [2005]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[RFC] subclasses in sysfs to solve world peace
    Ok, first off, I hate talking about architecture changes without showing
    the code for what I am talking about first, but as this is an issue that
    needs to be agreed upon by a wide range of developers, I'll just write
    up what I am thinking about doing before actually doing it...

    The problem: We need a way to show complex class and class device
    structures properly in sysfs. Examples of these "complex" views are the
    input layer's use of different input drivers for devices (usually the
    same device), the video subsystem view of frame buffer devices and
    monitors, and even the block layer with it's disks and partitions.

    Proposed solutions in the past have been either add the ability to nest
    classes themselves (as shown in Dmitry's recent proposal for fixing the
    input layer), or add the ability to nest class_device structures (I
    think others have tried to do this in the past, sorry for not
    remembering the specifics.) Both of these proposals don't really solve
    the real problem, that of the fact that we need to come up with a
    solution that all of the different subsystems can use properly.

    So, here's my take on it. Feel free to tell me what I messed up :)

    I would like to add something called "subclasses" for lack of a better
    term. These subclasses would have both drivers, and devices associated
    with them. This would show up as the following tree of directories:

    /sys/class/input/
    |-- input0
    | |-- event0
    | `-- mouse0
    |-- input1
    | |-- event1
    | `-- ts0
    |-- mice
    `-- drivers
    |-- event
    |-- mouse
    `-- ts

    Here we have 3 struct class_devices like today, input0, input1, and
    mice. We also have struct subclass_drivers of event, mouse, and ts.
    These will create the struct subclass_devices event0, mouse0, event1,
    and ts0. The "dev" node files will show up in the directories mice,
    event0, mouse0, event1, and ts0, like you would expect them too.

    So, this lets us create a solution for the input subsystem, but will it
    also work for block and video?

    For block, yes, I think so. There is no requirement for a
    subclass_driver to create the subclass devices. Any code can create and
    register with the class core a subclass device, just set up the parent
    pointer and away you go. So, in the following instance:
    /sys/class/block/
    `-- sda
    |-- sda1
    |-- sda2
    `-- sda3

    "block" would represent the struct class.
    "sda" would represent the struct class_device.
    "sda1", "sda2", and "sda3" would represent the different subclass
    devices that are bound to the class device "sda".

    And yes, before you all point out the class_interface logic, yes, the
    subclass_driver stuff looks a lot like this idea. Possibly we could
    just get rid of the interface stuff and use the subclass_driver logic,
    but I'd have to look at how people are using the interface logic before
    I can give a confident answer about that.

    Hotplug events would be simple with this scheme, the class stuff would
    remain the same, and the devpath would just point to the subdir (hotplug
    events would happen for both the class devices and the subclass
    devices.) And yes, udev and libsysfs would have to be changed to
    support this, so we better get this right before pushing it out to the
    world...

    But, what about video devices? David and Pat, we talked about this at
    OLS, but Pat kept the paper we drew on, and the beer we were drinking at
    the time has made my memory a bit fuzzy as to all of your requirements
    for the video subsystem. I remember things about frame buffers and
    monitors and other things like that, but nothing specific, sorry. Could
    you outline your needs and I'll see if this proposed structure would
    solve your issues?

    Well, that was a very brief summary, of which I know there are lots of
    questions for the areas I didn't explain well enough. Comments?
    Criticisms? Want to see the code before commenting?

    thanks,

    greg k-h
    -
    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/

    \
     
     \ /
      Last update: 2005-09-16 02:23    [W:0.040 / U:31.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site