* Re: [PATCH] /proc/scsi/map
@ 2002-06-25 16:33 ` Patrick Mochel
0 siblings, 0 replies; 22+ messages in thread
From: Patrick Mochel @ 2002-06-25 16:33 UTC (permalink / raw)
To: David Brownell; +Cc: Nick Bellinger, linux-kernel, linux-scsi
On Sat, 22 Jun 2002, David Brownell wrote:
> > On the other hand there is the obvious fact that an iSCSI initiator
> > driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> > etc, is out of the question. There is a real need for a solution to
> > handle virtual devices (as stated your previous message) that are not
> > assoicated with any physical connectors.
>
> There are those who see the IP stack as a kind of logical bus ... :)
> It's just not tied any specific hardware interface; it's "multipathed" in
> some sense. Linking it to an eth0 entry in $DRIVERFS/root/pci0/00:10.0
> would be wrong, since it can also be accessed through eth2.
It's not wrong, it's just makes life interesting when you want
accurately represent the presence of the device via both paths, or you
want to deal with the removal or power management of the bridge device.
That problem needs to be addressed; soon.
> Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... style
> hookup for iSCSI devices? Using whatever physical addressing the
> kernel uses there, which I assume wouldn't necessarily be restricted
> to ipv4. (And not exposing physical network topology -- routing! --
> in driverfs.)
You can very well use driverfs to expose those attributes, and is one of
the things that we've been discussing at the kernel summit. driverfs will
take over the world. But, I still think the device is best represented as
a child of the phsysical network device.
> On a related topic ... if driverfs is going to be providing a nice unique
> ID for the controller ($DRIVERFS/root/pci0/00:02.0/02:0f.0/03:07.0 for
> Linus' behind-two-bridges case), why are people talking as if the SCSI
> layer's arbitrary "controller number" should still be getting pushed as
> part of user visible names?
>
> That is, I'd sure hope the standard policy for assigning driverfs names
> would avoid _all_ IDs that are derived from enumeration order. Otherwise
> it'll be hard to store those names for (re)use by user mode tools.
The bus_id of the device is intended to represent the bus-specific ID of
the device, and is the name of the driverfs directory.
The name should user-friendly. It shouldn't be a unique name. Use
something nice and pretty. If people need/want a UUID, add it to the
bus-specific or type-specific structure, and export it via driverfs. It
will eventually make it to the generic structure.
-pat
^ permalink raw reply [flat|nested] 22+ messages in thread
* driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
2002-06-25 16:33 ` Patrick Mochel
(?)
@ 2002-06-25 17:47 ` David Brownell
2002-06-25 19:06 ` Patrick Mochel
-1 siblings, 1 reply; 22+ messages in thread
From: David Brownell @ 2002-06-25 17:47 UTC (permalink / raw)
To: Patrick Mochel; +Cc: Nick Bellinger, linux-kernel, linux-scsi
> The bus_id of the device is intended to represent the bus-specific ID of
> the device, and is the name of the driverfs directory.
Right, I was just commenting that the SCSI folk seem to like a particular
historical usage (based on driver enumeration order) that'd seem good to
do away with ... since it's not necessary (given the _real_ bus-specific
ID from their parent device) and has _always_ been problematic (those
enumeration-related IDs can change unexpectedly).
> The name should user-friendly. It shouldn't be a unique name. Use
> something nice and pretty.
I've been wondering about that. Right now PCI and USB both use fairly
unfriendly/unpretty values in device.name ... "{PCI,USB} device VVVV:PPPP".
Let me make sure I understand you right here, by examples of two
changes I'd like to see. Correct me if these seem wrong:
- It'd be more appropriate for PCI devices to copy pci_device.name into
device.name and get the user-friendly names from the PCI device name
database (when available), and only fallback to those nasty strings
when the more user-friendly names aren't available.
- Likewise it'd be more appropriate for USB devices to take the
descriptive strings from the devices, like "Philips USB Digital
Speaker System", than "USB device 0471:0104".
In both cases the current strings might make reasonable fallbacks
for the case when something better isn't available. But as examples,
I don't think they match a "user friendly, pretty" model ... :)
Would it be appropriate for device drivers to set the "name" in
some cases, or is that something you'd only expect bus drivers
to be setting up (once, and read-only)?
Given that in one common usage the "bus_id" is the "true name" of
those devices, I've thought that "description" might be a slightly
better way identify that attribute. "Name" is a word with a thousand
meanings, all of them context-dependent, and easily confused.
- Dave
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
2002-06-25 17:47 ` driverfs bus_id, name (was: [PATCH] /proc/scsi/map) David Brownell
@ 2002-06-25 19:06 ` Patrick Mochel
0 siblings, 0 replies; 22+ messages in thread
From: Patrick Mochel @ 2002-06-25 19:06 UTC (permalink / raw)
To: David Brownell; +Cc: Nick Bellinger, linux-kernel, linux-scsi
> I've been wondering about that. Right now PCI and USB both use fairly
> unfriendly/unpretty values in device.name ... "{PCI,USB} device VVVV:PPPP".
>
> Let me make sure I understand you right here, by examples of two
> changes I'd like to see. Correct me if these seem wrong:
>
> - It'd be more appropriate for PCI devices to copy pci_device.name into
> device.name and get the user-friendly names from the PCI device name
> database (when available), and only fallback to those nasty strings
> when the more user-friendly names aren't available.
That is what happens with PCI devices. They're not appearing as meaningful
names probably because CONFIG_PCI_NAMES isn't set. Whether or not that
information belongs in the kernel is another debate.
I believe the SCSI people mentioned something about being able to set
those from userspace. I'm not opposed to such an idea. You just need a
writable name file.
> - Likewise it'd be more appropriate for USB devices to take the
> descriptive strings from the devices, like "Philips USB Digital
> Speaker System", than "USB device 0471:0104".
Those are in the devices themselves, right? There is nothing stopping the
USB people from doing that... ;)
-pat
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
@ 2002-06-25 19:06 ` Patrick Mochel
0 siblings, 0 replies; 22+ messages in thread
From: Patrick Mochel @ 2002-06-25 19:06 UTC (permalink / raw)
To: David Brownell; +Cc: Nick Bellinger, linux-kernel, linux-scsi
> I've been wondering about that. Right now PCI and USB both use fairly
> unfriendly/unpretty values in device.name ... "{PCI,USB} device VVVV:PPPP".
>
> Let me make sure I understand you right here, by examples of two
> changes I'd like to see. Correct me if these seem wrong:
>
> - It'd be more appropriate for PCI devices to copy pci_device.name into
> device.name and get the user-friendly names from the PCI device name
> database (when available), and only fallback to those nasty strings
> when the more user-friendly names aren't available.
That is what happens with PCI devices. They're not appearing as meaningful
names probably because CONFIG_PCI_NAMES isn't set. Whether or not that
information belongs in the kernel is another debate.
I believe the SCSI people mentioned something about being able to set
those from userspace. I'm not opposed to such an idea. You just need a
writable name file.
> - Likewise it'd be more appropriate for USB devices to take the
> descriptive strings from the devices, like "Philips USB Digital
> Speaker System", than "USB device 0471:0104".
Those are in the devices themselves, right? There is nothing stopping the
USB people from doing that... ;)
-pat
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
2002-06-25 19:06 ` Patrick Mochel
(?)
@ 2002-06-25 19:55 ` David Brownell
2002-07-01 17:25 ` Patrick Mochel
-1 siblings, 1 reply; 22+ messages in thread
From: David Brownell @ 2002-06-25 19:55 UTC (permalink / raw)
To: Patrick Mochel; +Cc: Nick Bellinger, linux-kernel, linux-scsi
>>- It'd be more appropriate for PCI devices to copy pci_device.name into
>> device.name and get the user-friendly names from the PCI device name
>> database (when available), and only fallback to those nasty strings
>> when the more user-friendly names aren't available.
>
>
> That is what happens with PCI devices. They're not appearing as meaningful
> names probably because CONFIG_PCI_NAMES isn't set. Whether or not that
> information belongs in the kernel is another debate.
ERm ... it wasn't on the systems I looked at. CONFIG_PCI_NAMES has
clearly been set, but the names were the user-unfriendly style. And
yet I know the kernel has them accessible, since they're presented
by the USB layer and by /proc/pci. But not in driverfs.
I now see some code (presumably yours) to set those two fields
to be identical, in pci_scan_device(), but the useful description
is instead set in pci_scan_slot(). Presumably this is a case of
various init paths in PCI not wholly agreeing with each other;
maybe pci_name_device() should set both name/description fields
instead of only the one. (Though ... why have two copies? :)
>>- Likewise it'd be more appropriate for USB devices to take the
>> descriptive strings from the devices, like "Philips USB Digital
>> Speaker System", than "USB device 0471:0104".
>
>
> Those are in the devices themselves, right? There is nothing stopping the
> USB people from doing that... ;)
Good, I was just sanity checking ... since the PCI names really
haven't worked to provide user-friendly names, and I couldn't tell
if that was intentional. I can provide a patch for USB easily.
You didn't respond to the question about changing the identifier
from "name" to be the more appropriate "description" ... is that
because you're still thinking (it'd cost to change) or because
you like using the (IMO ambiguous) identifier "name" there?
- Dave
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: driverfs bus_id, name (was: [PATCH] /proc/scsi/map)
2002-06-25 19:55 ` David Brownell
@ 2002-07-01 17:25 ` Patrick Mochel
0 siblings, 0 replies; 22+ messages in thread
From: Patrick Mochel @ 2002-07-01 17:25 UTC (permalink / raw)
To: David Brownell; +Cc: linux-kernel
On Tue, 25 Jun 2002, David Brownell wrote:
> >>- It'd be more appropriate for PCI devices to copy pci_device.name into
> >> device.name and get the user-friendly names from the PCI device name
> >> database (when available), and only fallback to those nasty strings
> >> when the more user-friendly names aren't available.
> >
> >
> > That is what happens with PCI devices. They're not appearing as meaningful
> > names probably because CONFIG_PCI_NAMES isn't set. Whether or not that
> > information belongs in the kernel is another debate.
>
> ERm ... it wasn't on the systems I looked at. CONFIG_PCI_NAMES has
> clearly been set, but the names were the user-unfriendly style. And
> yet I know the kernel has them accessible, since they're presented
> by the USB layer and by /proc/pci. But not in driverfs.
>
> I now see some code (presumably yours) to set those two fields
> to be identical, in pci_scan_device(), but the useful description
> is instead set in pci_scan_slot(). Presumably this is a case of
> various init paths in PCI not wholly agreeing with each other;
> maybe pci_name_device() should set both name/description fields
> instead of only the one. (Though ... why have two copies? :)
Hrm, they do appear to be out of sync. Thanks for pointing that out.
> You didn't respond to the question about changing the identifier
> from "name" to be the more appropriate "description" ... is that
> because you're still thinking (it'd cost to change) or because
> you like using the (IMO ambiguous) identifier "name" there?
That's what the name field is - the ascii description of the device. I
understand that "description" is more obvious, so I'll consider the
change.
-pat
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] /proc/scsi/map
2002-06-25 16:33 ` Patrick Mochel
(?)
(?)
@ 2002-06-25 17:49 ` David Brownell
2002-06-26 23:39 ` Nick Bellinger
` (2 more replies)
-1 siblings, 3 replies; 22+ messages in thread
From: David Brownell @ 2002-06-25 17:49 UTC (permalink / raw)
To: Patrick Mochel; +Cc: Nick Bellinger, linux-kernel, linux-scsi
>>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... style
>>hookup for iSCSI devices? Using whatever physical addressing the
>>kernel uses there, which I assume wouldn't necessarily be restricted
>>to ipv4. (And not exposing physical network topology -- routing! --
>>in driverfs.)
>
>
> You can very well use driverfs to expose those attributes, and is one of
> the things that we've been discussing at the kernel summit. driverfs will
> take over the world. But, I still think the device is best represented as
> a child of the phsysical network device.
Which one? I'd certainly hope that drivers wouldn't have to choose which
of the various network interfaces to register under, or register under
every network interface concurrently. (Or only the ones they might
conceivably be routed to go out on...) Given a bonded network link (going
out over multiple physical drivers) that'd get hairy. And what about
devices that host several logical interfaces? Or when the interfaces get
moved to some other device?
That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
sensible in such cases. Which is not to say it's without additional issues
(like how to establish/maintain driver linkages that are DAGs not single
parent trees) but it wouldn't require drivers to dig as deeply into lower
levels of their stack. (And some network interfaces might well live in
such a non-physical tree, not just iSCSI...)
I think that problem wouldn't quite be isomorphic to multipath access to
devices, though it seems to be related. "Driver stacking" is an area
that "driverfs" doesn't seem to address quite yet ... not needed in the
simpler driver scenarios, so that's what I'd expect at this stage.
- Dave
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] /proc/scsi/map
2002-06-25 17:49 ` [PATCH] /proc/scsi/map David Brownell
@ 2002-06-26 23:39 ` Nick Bellinger
2002-07-01 17:45 ` Patrick Mochel
2002-07-03 0:59 ` Pavel Machek
2002-07-03 0:59 ` Pavel Machek
2 siblings, 1 reply; 22+ messages in thread
From: Nick Bellinger @ 2002-06-26 23:39 UTC (permalink / raw)
To: David Brownell; +Cc: Patrick Mochel, linux-kernel, linux-scsi
On Tue, 2002-06-25 at 11:49, David Brownell wrote:
> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... style
> >>hookup for iSCSI devices? Using whatever physical addressing the
> >>kernel uses there, which I assume wouldn't necessarily be restricted
> >>to ipv4. (And not exposing physical network topology -- routing! --
> >>in driverfs.)
> >
> >
> > You can very well use driverfs to expose those attributes, and is one of
> > the things that we've been discussing at the kernel summit. driverfs will
> > take over the world. But, I still think the device is best represented as
> > a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
I hate to kick the already deceased horse but..
This appears to be one of the larger problems that nobody (aside from
this thread :) seems to be raising. I understand Pat's logic of wanting
to keep the logical device a child of the network card, but in many
situations (espically the enterprise ones with regard multipathed IP
storage, along with David's examples above) I just dont see how that can
be done correctly in keeping all the prementioned virtual devices part
of the network device's directory in the tree.
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into lower
> levels of their stack. (And some network interfaces might well live in
> such a non-physical tree, not just iSCSI...)
>
I am in complete agreement, from my little view of where driverfs
currently stands a non-physical tree is going to have to happen sooner
or later, why not now?
> I think that problem wouldn't quite be isomorphic to multipath access to
> devices, though it seems to be related. "Driver stacking" is an area
> that "driverfs" doesn't seem to address quite yet ... not needed in the
> simpler driver scenarios, so that's what I'd expect at this stage.
>
> - Dave
>
Thanks!
Nicholas Bellinger
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] /proc/scsi/map
2002-06-26 23:39 ` Nick Bellinger
@ 2002-07-01 17:45 ` Patrick Mochel
0 siblings, 0 replies; 22+ messages in thread
From: Patrick Mochel @ 2002-07-01 17:45 UTC (permalink / raw)
To: Nick Bellinger; +Cc: linux-kernel
> > That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> > sensible in such cases. Which is not to say it's without additional issues
> > (like how to establish/maintain driver linkages that are DAGs not single
> > parent trees) but it wouldn't require drivers to dig as deeply into lower
> > levels of their stack. (And some network interfaces might well live in
> > such a non-physical tree, not just iSCSI...)
> >
>
> I am in complete agreement, from my little view of where driverfs
> currently stands a non-physical tree is going to have to happen sooner
> or later, why not now?
No. The physical hierarchy in driverfs is meant to be as accurate as
possible. Yes, it's idealistic, and at some point we might have to make a
bit of an exception. But, I refuse to break that model yet.
-pat
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] /proc/scsi/map
2002-06-25 17:49 ` [PATCH] /proc/scsi/map David Brownell
2002-06-26 23:39 ` Nick Bellinger
@ 2002-07-03 0:59 ` Pavel Machek
2002-07-03 0:59 ` Pavel Machek
2 siblings, 0 replies; 22+ messages in thread
From: Pavel Machek @ 2002-07-03 0:59 UTC (permalink / raw)
To: David Brownell; +Cc: Patrick Mochel, Nick Bellinger, linux-kernel, linux-scsi
Hi!
> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... style
> >>hookup for iSCSI devices? Using whatever physical addressing the
> >>kernel uses there, which I assume wouldn't necessarily be restricted
> >>to ipv4. (And not exposing physical network topology -- routing! --
> >>in driverfs.)
> >
> >
> >You can very well use driverfs to expose those attributes, and is one of
> >the things that we've been discussing at the kernel summit. driverfs will
> >take over the world. But, I still think the device is best represented as
> >a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into
> >>lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason
why it could not exist with some kind of advanced fibrechannel.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] /proc/scsi/map
2002-06-25 17:49 ` [PATCH] /proc/scsi/map David Brownell
2002-06-26 23:39 ` Nick Bellinger
2002-07-03 0:59 ` Pavel Machek
@ 2002-07-03 0:59 ` Pavel Machek
2 siblings, 0 replies; 22+ messages in thread
From: Pavel Machek @ 2002-07-03 0:59 UTC (permalink / raw)
To: David Brownell; +Cc: Patrick Mochel, Nick Bellinger, linux-kernel, linux-scsi
Hi!
> >>Why shouldn't there be a $DRIVERFS/net/ipv4@10.42.135.99/... style
> >>hookup for iSCSI devices? Using whatever physical addressing the
> >>kernel uses there, which I assume wouldn't necessarily be restricted
> >>to ipv4. (And not exposing physical network topology -- routing! --
> >>in driverfs.)
> >
> >
> >You can very well use driverfs to expose those attributes, and is one of
> >the things that we've been discussing at the kernel summit. driverfs will
> >take over the world. But, I still think the device is best represented as
> >a child of the phsysical network device.
>
> Which one? I'd certainly hope that drivers wouldn't have to choose which
> of the various network interfaces to register under, or register under
> every network interface concurrently. (Or only the ones they might
> conceivably be routed to go out on...) Given a bonded network link (going
> out over multiple physical drivers) that'd get hairy. And what about
> devices that host several logical interfaces? Or when the interfaces get
> moved to some other device?
>
> That's why I think a "non-physical" tree (not under $DRIVERFS/root) is more
> sensible in such cases. Which is not to say it's without additional issues
> (like how to establish/maintain driver linkages that are DAGs not single
> parent trees) but it wouldn't require drivers to dig as deeply into
> >>lower
Hmm, are dags enough?
I mean, cycles exist in IP based networks, and I don't see a reason
why it could not exist with some kind of advanced fibrechannel.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
^ permalink raw reply [flat|nested] 22+ messages in thread