From: Greg KH <greg@kroah.com>
To: Jeremy Katz <katzj@redhat.com>
Cc: Pete Zaitcev <zaitcev@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: "block" symlink in sysfs for a multifunction device
Date: Thu, 15 Dec 2005 08:53:57 -0800 [thread overview]
Message-ID: <20051215165357.GA15016@kroah.com> (raw)
In-Reply-To: <1134622055.2864.21.camel@bree.local.net>
On Wed, Dec 14, 2005 at 11:47:35PM -0500, Jeremy Katz wrote:
> On Wed, 2005-12-14 at 15:42 -0800, Greg KH wrote:
> > On Wed, Dec 14, 2005 at 03:26:15PM -0800, Pete Zaitcev wrote:
> > > On Tue, 13 Dec 2005 21:50:19 -0800, Greg KH <greg@kroah.com> wrote:
> > > > $ ls -l /sys/block/uba/device/
> > > > -r--r--r-- 1 root root 4096 Dec 13 21:31 bNumEndpoints
> > > > lrwxrwxrwx 1 root root 0 Dec 13 21:31 block:uba -> ../../../../../../block/uba
> > > > lrwxrwxrwx 1 root root 0 Dec 13 21:31 block:ubb -> ../../../../../../block/ubb
> > > > lrwxrwxrwx 1 root root 0 Dec 13 21:31 block:ubc -> ../../../../../../block/ubc
> > > > lrwxrwxrwx 1 root root 0 Dec 13 21:31 block:ubd -> ../../../../../../block/ubd
> > >
> > > Greg, Jeremy is not happy about this.
> > >
> > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175563
> > > > ------- Additional Comments From katzj@redhat.com 2005-12-14 18:05 EST -------
> > > > Actually, this is problematic. It makes it so that the single device directory
> > > > corresponds to more than one device which we can't handle with kudzu :-(
> >
> > Well, how do you handle it for class devices then?
>
> We don't have any where we need to handle it at present.
>
> > And if this isn't acceptable, what would be?
>
> By going this route, it really feels like you're hacking around your own
> rule of a single value per file :-) Except that instead of having a
> file that I read five values from, it's five files with naming
> heuristics to get five values. Which is, in a lot of ways, worse.
What? These are symlinks, not files. Why would you want to read the
name of the block device from a file and then go have to look that
location up, instead of just following the symlink?
> I'd much rather see the fact that there are multiple devices be handled
> by having each device with its own unique directory. This then keeps
> all of the abstractions which currently exist.
Those devices do have their own unique directory. Look at the pointer
above :)
The point here is that multiple class devices and block devices can bind
to a single "real device" in the system, and we need to handle that
representation properly. We have had the symlink for a while now, and I
just forgot to put the proper name on the block device one, to match up
with the class device naming.
thanks,
greg k-h
prev parent reply other threads:[~2005-12-15 16:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-12 21:49 "block" symlink in sysfs for a multifunction device Pete Zaitcev
2005-12-12 21:53 ` Russell King
2005-12-14 5:50 ` Greg KH
2005-12-14 6:58 ` Pete Zaitcev
2005-12-14 23:26 ` Pete Zaitcev
2005-12-14 23:42 ` Greg KH
2005-12-15 0:10 ` Pete Zaitcev
2005-12-15 0:44 ` Greg KH
2005-12-15 2:47 ` Bill Nottingham
2005-12-15 4:47 ` Jeremy Katz
2005-12-15 16:53 ` Greg KH [this message]
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=20051215165357.GA15016@kroah.com \
--to=greg@kroah.com \
--cc=katzj@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/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).