From: Ben Hutchings <ben@decadent.org.uk>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Greg Kroah-Hartman <gregkh@suse.de>, Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
linux-fsdevel@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>,
Benjamin LaHaise <bcrl@lhnet.ca>, Serge Hallyn <serue@us.ibm.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 0/6] tagged sysfs support
Date: Sat, 03 Apr 2010 17:05:56 +0100 [thread overview]
Message-ID: <1270310756.12516.308.camel@localhost> (raw)
In-Reply-To: <h2gac3eb2511004030135q2a2f5002z912974c1d2ab8853@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
> On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben@decadent.org.uk> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2010-04-03 16:05 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 18:30 [PATCH 0/6] tagged sysfs support Eric W. Biederman
2010-03-30 18:31 ` [PATCH 1/6] sysfs: Basic support for multiple super blocks Eric W. Biederman
2010-03-30 19:23 ` Eric Dumazet
2010-03-30 23:50 ` [PATCH 7/6] sysfs: Remove double free sysfs_get_sb Eric W. Biederman
2010-03-31 5:01 ` [PATCH 1/6] sysfs: Basic support for multiple super blocks Serge E. Hallyn
2010-03-31 5:01 ` Serge E. Hallyn
2010-03-31 5:41 ` Tejun Heo
2010-03-31 5:51 ` Eric W. Biederman
2010-03-31 13:47 ` Serge E. Hallyn
2010-03-31 14:02 ` Eric W. Biederman
2010-04-05 7:45 ` Tejun Heo
2010-03-30 18:31 ` [PATCH 2/6] kobj: Add basic infrastructure for dealing with namespaces Eric W. Biederman
2010-03-30 18:31 ` [PATCH 3/6] sysfs: Implement sysfs tagged directory support Eric W. Biederman
2010-03-31 2:43 ` Serge E. Hallyn
2010-03-31 3:38 ` Eric W. Biederman
2010-03-31 4:02 ` Serge E. Hallyn
2010-03-31 4:23 ` Eric W. Biederman
2010-03-31 4:53 ` Serge E. Hallyn
2010-03-31 6:49 ` Tejun Heo
2010-03-31 7:43 ` Eric W. Biederman
2010-03-31 8:17 ` Tejun Heo
2010-03-31 8:22 ` Tejun Heo
2010-03-31 9:39 ` Eric W. Biederman
2010-04-05 8:17 ` Tejun Heo
2010-03-30 18:31 ` [PATCH 4/6] sysfs: Add support for tagged directories with untagged members Eric W. Biederman
2010-03-30 18:31 ` [PATCH 5/6] sysfs: Implement sysfs_delete_link Eric W. Biederman
2010-03-30 18:31 ` [PATCH 6/6] driver core: Implement ns directory support for device classes Eric W. Biederman
2010-03-30 18:53 ` [PATCH 0/6] tagged sysfs support Kay Sievers
2010-03-30 23:04 ` Eric W. Biederman
2010-03-31 5:51 ` Kay Sievers
2010-03-31 6:25 ` Tejun Heo
2010-03-31 6:52 ` Eric W. Biederman
2010-04-03 0:58 ` Ben Hutchings
2010-04-03 8:35 ` Kay Sievers
2010-04-03 16:05 ` Ben Hutchings [this message]
2010-04-03 16:35 ` Kay Sievers
2010-03-31 17:21 ` Serge E. Hallyn
2010-03-31 18:09 ` Eric W. Biederman
2010-05-20 17:47 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1270310756.12516.308.camel@localhost \
--to=ben@decadent.org.uk \
--cc=bcrl@lhnet.ca \
--cc=cornelia.huck@de.ibm.com \
--cc=ebiederm@xmission.com \
--cc=eric.dumazet@gmail.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=serue@us.ibm.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).