linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).