On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote: > On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben@xxxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part