From: Arnd Bergmann <arnd@arndb.de>
To: Greg KH <gregkh@suse.de>, Kay Sievers <kay.sievers@vrfy.org>
Cc: Jamie Iles <jamie@jamieiles.com>,
linux-kernel@vger.kernel.org, vapier@gentoo.org
Subject: Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory
Date: Mon, 28 Mar 2011 15:11:00 +0200 [thread overview]
Message-ID: <201103281511.00621.arnd@arndb.de> (raw)
In-Reply-To: <20110326151050.GA27822@suse.de>
On Saturday 26 March 2011, Greg KH wrote:
> On Sat, Mar 26, 2011 at 12:25:03PM +0100, Arnd Bergmann wrote:
> > On Saturday 26 March 2011 00:28:47 Greg KH wrote:
> >
> > > Yes, that is how it used to be, but then it turns out that both of them
> > > are really just "subsystems" as far as it all goes. They are just ways
> > > that devices are bound to drivers in a logical manner. We have patches
> > > floating around that get rid of both busses and classes to merge them
> > > together, which is the end goal here. I know Kay has posted detailed
> > > reasons for why this all is on lkml in the past, and had working code
> > > about 5 years ago, it's just been slow going...
> >
> > How will that work? I suppose we can't really change the directory
> > structure anyway, so to users it will still look like it does today,
> > even if the kernel just uses the same code for bus and class internally.
>
> Yes. But we can have symlinks instead of "real" /sys/class and
> /sys/bus directories like we do for /sys/block today. All of the major
> tools that use sysfs work properly with a /sys/subsystem/ setup today
> thanks to Kay's efforts.
I see. The migration from /sys/bus to /sys/subsystem plus symlinks
makes sense, but I still think that having symlinks that make sense
would be better than having symlinks that are purely there for historical
reasons.
One major flaw I see with registering abstract subsystems as a bus is
that a bus connected to the concept of a device_driver, and there is
a list of drivers with their respective devices in /sys/bus/*/drivers,
which would always be empty in this case. Similarly, the
/sys/bus/*/devices/*/driver symlinks for these subsystems would point
to drivers on other buses, unlike the respective symlinks for real
buses.
Arnd
next prev parent reply other threads:[~2011-03-28 13:11 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 15:21 [RFC PATCHv2 0/4] Support for OTP memory Jamie Iles
2011-03-24 15:21 ` [RFC PATCHv2 1/4] drivers/otp: add initial support " Jamie Iles
2011-03-24 18:32 ` Mike Frysinger
2011-03-24 20:35 ` Jamie Iles
2011-03-24 21:33 ` Mike Frysinger
2011-03-25 10:08 ` Jamie Iles
2011-03-25 21:32 ` Mike Frysinger
2011-03-25 22:27 ` Jamie Iles
2011-03-25 22:36 ` Mike Frysinger
2011-03-24 19:20 ` Greg KH
2011-03-24 20:49 ` Jamie Iles
2011-03-25 20:12 ` Arnd Bergmann
2011-03-25 21:12 ` Greg KH
2011-03-25 22:01 ` Arnd Bergmann
2011-03-25 23:28 ` Greg KH
2011-03-26 11:25 ` Arnd Bergmann
2011-03-26 15:10 ` Greg KH
2011-03-28 13:11 ` Arnd Bergmann [this message]
2011-03-25 22:23 ` Jamie Iles
2011-03-25 22:35 ` Arnd Bergmann
2011-03-25 22:38 ` Mike Frysinger
2011-03-25 22:52 ` Jamie Iles
2011-03-25 23:02 ` Arnd Bergmann
2011-03-26 0:21 ` Jamie Iles
2011-03-26 2:16 ` Mike Frysinger
2011-03-26 2:40 ` Jamie Iles
2011-03-26 10:54 ` Arnd Bergmann
2011-03-26 17:55 ` Mike Frysinger
2011-03-26 20:51 ` Arnd Bergmann
2011-03-27 3:52 ` Mike Frysinger
2011-03-27 11:18 ` Arnd Bergmann
2011-03-25 22:53 ` Arnd Bergmann
2011-03-24 15:21 ` [RFC PATCHv2 2/4] drivers/otp: add support for Picoxcell PC3X3 OTP Jamie Iles
2011-03-24 18:50 ` Mike Frysinger
2011-03-24 20:59 ` Jamie Iles
2011-03-24 21:40 ` Mike Frysinger
2011-03-24 15:21 ` [RFC PATCHv2 3/4] drivers/otp: allow an ioctl to be specified Jamie Iles
2011-03-24 18:35 ` Mike Frysinger
2011-03-24 20:36 ` Jamie Iles
2011-03-24 15:21 ` [RFC PATCHv2 4/4] drivers/otp: convert bfin otp to generic OTP Jamie Iles
2011-03-24 18:52 ` Mike Frysinger
2011-03-24 20:40 ` Jamie Iles
2011-03-24 17:39 ` [RFC PATCHv2 0/4] Support for OTP memory Mike Frysinger
2011-03-24 17:47 ` Jamie Iles
2011-03-24 17:56 ` Mike Frysinger
2011-03-24 18:32 ` Jamie Iles
2011-03-24 18:36 ` Mike Frysinger
2011-03-24 20:38 ` Jamie Iles
2011-03-25 0:12 ` Mark Brown
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=201103281511.00621.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=gregkh@suse.de \
--cc=jamie@jamieiles.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier@gentoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.