From: James Smart <James.Smart@Emulex.Com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Greg KH <greg@kroah.com>,
linux-scsi@vger.kernel.org, Tony Jones <tonyj@suse.de>
Subject: Re: [patch] convert the scsi layer to use struct device
Date: Mon, 17 Mar 2008 00:15:25 -0400 [thread overview]
Message-ID: <47DDF05D.8060608@emulex.com> (raw)
In-Reply-To: <1205701470.11374.66.camel@lov.site>
Kay Sievers wrote:
>> Well, the <classname> prefix came about because there was namespace overlap
>> between different classes (e.g. scsi_host and fc_host classes use the same name,
>> and I think where we originally saw this was in the way serial ports were enumerated
>> for some base systems as well).
>>
>> So I don't see how you can kill the <classname>:<devname> names by SYSFS_DEPRECATED.
>
> With SYSFS_DEPRECATED, nothing will change. But these links don't exist
> with !SYSFS_DEPRECATED, because the class devices live in
> subdirectories, named after the class they come from, there is no
> namespace problem, or any problem to find these devices, you don't even
> need readdir() to look them up.
Ok, it should have read :
I don't see how you can kill the <classname>:<devname> names w/ !SYSFS_DEPRECATED.
You still haven't answered my question about namespace overlap. What happens when the
device belongs to multiple classes, and the classes have the same name for the class
device ? I don't believe we ever want to be in the case where the classes have to
understand a global namespace.
I know this exists a couple of places, because it's what drove us to using the "<class_nm>:"
prefix in the beginning. Additionally, I know of several utilities that found a lot
of benefit to having the class name. For example, the different transports in scsi all
use the same names for their devices, which overlap with the scsi_host name. The utility
could use the prefix to understand what class the device belonged to. What do you have
to replace this with ? - a symlink to the /sys/class symlink ? a pattern matching on
what attributes exist (and optional attributes make this ugly) ? a new sysfs attributes
in the object, say class, that spits out the class name ?
Keeping the prefix may also be useful to distinguish between class devices and real
child devices.
-- james s
next prev parent reply other threads:[~2008-03-17 4:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-13 21:06 [patch] convert the scsi layer to use struct device Greg KH
2008-03-14 14:13 ` Hannes Reinecke
2008-03-14 17:15 ` James Bottomley
2008-03-14 21:20 ` James Bottomley
2008-03-14 21:58 ` Kay Sievers
2008-03-15 14:19 ` James Bottomley
2008-03-15 15:17 ` Kay Sievers
2008-03-15 16:16 ` James Bottomley
2008-03-15 18:01 ` James Bottomley
2008-03-15 18:26 ` Kay Sievers
2008-03-15 18:34 ` James Bottomley
2008-03-15 20:38 ` Stefan Richter
2008-03-15 18:04 ` Kay Sievers
2008-03-15 18:31 ` James Bottomley
2008-03-15 18:56 ` Kay Sievers
2008-03-15 19:33 ` James Bottomley
2008-03-15 19:43 ` Kay Sievers
2008-03-16 20:21 ` James Smart
2008-03-16 21:04 ` Kay Sievers
2008-03-17 4:15 ` James Smart [this message]
2008-03-17 5:35 ` Greg KH
2008-03-17 12:18 ` James Smart
2008-03-17 13:40 ` Kay Sievers
2008-03-17 13:55 ` James Bottomley
2008-03-17 17:57 ` James Bottomley
2008-03-19 0:48 ` Greg KH
2008-03-19 20:38 ` James Bottomley
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=47DDF05D.8060608@emulex.com \
--to=james.smart@emulex.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tonyj@suse.de \
/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