On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote:
> On Wed, Mar 31, 2010 at 01:04, Eric W. Biederman <[email protected]> wrote:
> > Kay Sievers <[email protected]> writes:
> >> On Tue, Mar 30, 2010 at 20:30, Eric W. Biederman <[email protected]> wrote:
> >>>
> >>> The main short coming of using multiple network namespaces today
> >>> is that only network devices for the primary network namespaces
> >>> can be put in the kobject layer and sysfs.
> >>>
> >>> This is essentially the earlier version of this patchset that was
> >>> reviewed before, just now on top of a version of sysfs that doesn't
> >>> need cleanup patches to support it.
> >>
> >> Just to check if we are not in conflict with planned changes, and how
> >> to possibly handle them:
> >>
> >> There is the plan and ongoing work to unify classes and buses, export
> >> them at /sys/subsystem in the same layout of the current /sys/bus/.
> >> The decision to export buses and classes as two different things
> >> (which they aren't) is the last major piece in the sysfs layout which
> >> needs to be fixed.
> >
> > Interesting. We will symlinks ie:
> > /sys/class -> /sys/subsystem
> > /sys/bus -> /sys/subsystem
> > to keep from breaking userspace.
>
> 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, but as for abstracting the difference
between bus and class... why?
Each bus defines a device interface covering enumeration,
identification, power management and various aspects of their connection
to the host. This interface is implemented by the bus driver.
Each class defines a device interface covering functionality provided to
user-space or higher level kernel components (block interface to
filesystems, net driver interface to the networking core, etc). This
interface is implemented by multiple device-specific drivers.
So while buses and classes both define device interfaces, they are
fundamentally different types of interface. And there are 'subsystems'
that don't have devices at all (time, RCU, perf, ...). If you're going
to expose the set of subsystems, don't they belong in there? But then,
what would you put in their directories?
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <[email protected]> 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. And
"usb" are devices, which are more a class of devices, and the
interfaces and contollers belong to a bus.
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.
> Each bus defines a device interface covering enumeration,
> identification, power management and various aspects of their connection
> to the host. This interface is implemented by the bus driver.
Sure, but that does not mean that class is a useful layout, or that
class devices can not do the same.
> Each class defines a device interface covering functionality provided to
> user-space or higher level kernel components (block interface to
> filesystems, net driver interface to the networking core, etc). This
> interface is implemented by multiple device-specific drivers.
That's absolutely wrong. Classes are just too simple uses of the same
thing. We have many class devices which are not "interfaces", and we
have bus devices which are interfaces.
> 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".
> And there are 'subsystems'
> that don't have devices at all (time, RCU, perf, ...). If you're going
> to expose the set of subsystems, don't they belong in there?
> But then,
We are talking about the current users in /sys, and the difference in
the sysfs export between /sys/bus and /sys/class.
> what would you put in their directories?
We are not talking about anything not in /sys currently.
Kay
On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
> On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <[email protected]> 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.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
On Sat, Apr 3, 2010 at 18:05, Ben Hutchings <[email protected]> wrote:
> On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
>> On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <[email protected]> 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?
The current inputX devices, unlike eventX and mouseX, are like "bus devices".
>> 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?
A device file per example, which can do anything to the device. :)
>> 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?
i2c, iio, and a few which have been out-of-tree and got changed before
the merge, because we knew they would not work as class devices, cause
of the need to have childs, or the need to add additional properties
at the subsystem directory level, just like pci, which has a "slots"
directory at the pci subsystem directory, such stuff is not possible
with the too simple class layout.
> [...]
>> > 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?
Just like /sys/block is doing it, /sys/class, /sys/bus will stay as
symlinks, and not go away.
Kay