[lkml]   [2010]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/6] tagged sysfs support
    On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
    > On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <> wrote:
    > > On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote:
    > >> Yeah, /sys/bus/, which is the only sane layout of the needlessly
    > >> different 3 versions of the same thing (bus, class, block).
    > > [...]
    > >
    > > block vs class/block is arguable,
    > That's already done long ago.
    > > but as for abstracting the difference
    > > between bus and class... why?
    > There is absolutely no need to needlessly export two versions of the
    > same thing. These directories serve no other purpose than to collect
    > all devices of the same subsystem. There is no useful information that
    > belongs to the type class or bus, they are both the same. Like
    > "inputX" is implemented as a class, but is much more like a bus.

    Really, how do you enumerate 'input' buses?

    > And "usb" are devices, which are more a class of devices, and the
    > interfaces and contollers belong to a bus.

    What common higher-level functionality do USB devices provide?

    > There is really no point to make userspace needlessly complicated to
    > distinguish the both.
    > We also have already a buch of subsystems which moved from class to
    > bus because they needed to express hierarchy between the same devices.
    > So the goal is to have only one type of subsystem to solve these
    > problems.

    That's interesting. Which were those?

    > > So while buses and classes both define device interfaces, they are
    > > fundamentally different types of interface.
    > No, they are not. They are just "devices". There is no useful
    > difference these two different types expose. And the class layout is
    > fundamentally broken, and not extendable. Peole mix lists of devices
    > with custom subsystem-wide attributes, which we need to stop from
    > doing this. The bus layout can carry custom directories, which is why
    > we want that by default for all "classifications".

    I understand that you want to clean up a mess, but how do you know
    you're not going to break user-space that depends on some of this mess?


    Ben Hutchings
    Once a job is fouled up, anything done to improve it makes it worse.
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2010-04-03 18:09    [W:0.035 / U:5.164 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site