lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 03 Apr 2010 17:05:56 +0100
From:	Ben Hutchings <>
To:	Kay Sievers <>
Cc:	"Eric W. Biederman" <>,
	Greg Kroah-Hartman <>, Greg KH <>,, Tejun Heo <>,
	Cornelia Huck <>,,
	Eric Dumazet <>,
	Benjamin LaHaise <>,
	Serge Hallyn <>,
Subject: Re: [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.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists