> From: Nick Bellinger [mailto:[email protected]]
> Giving the IP stack its own directory (leaf?) under driverfs
> root sounds
> interesting enough and could have some potential uses, but in the case
> of iSCSI there are a few problems:
I know this is one of those things that has more and more cool possibilities
the more you think about it but...
Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
in devicefs.
The device tree (for which devicefs is the fs representation) was originally
meant to enable good device power management and configuration. driverfs
wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
should it have to.
Regards -- Andy
> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.
What's "devicefs" -- some new filesystem? Or a mis/re-naming of "driverfs"?
I assume you don't mean "devfs".
> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration.
Surely a driver using IP-over-wire like iSCSI is no less deserving of appearing
in "driverfs" than one whose driver uses custom-protocol-over-a-"wire" like USB,
FireWire, FC, IR, SCSI, or Bluetooth? I don't see why some disks (for example)
should deserve to be "more equal than others" -- and approved to be in driverfs.
Admittedly some of those may have few power management concerns beyond basic
startup/shutdown sequencing. But the configuration management issues won't
go away just because a driver talks to a device over some more generalized
notion of wire. I suspect those are probably more important, long-term, than
the power management hooks. I seem to recall other operating systems starting
out with a device/driver tree well before power management existed, and was
surprised when I noticed Linux didn't have one yet.
No, of course driverfs isn't for everything. But if it's not for all drivers,
then what's it for -- just power management?
- Dave
On Sun, 2002-06-23 at 16:59, Grover, Andrew wrote:
> > From: Nick Bellinger [mailto:[email protected]]
> > Giving the IP stack its own directory (leaf?) under driverfs
> > root sounds
> > interesting enough and could have some potential uses, but in the case
> > of iSCSI there are a few problems:
>
> I know this is one of those things that has more and more cool possibilities
> the more you think about it but...
>
> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.
This is a red herring, what exactly is the definition of physically
hooked up to the computer? In the above context it comes out as being a
device inside the machine or within close proximity (ie: USB, IEEE 1394,
etc) and connected by a physical cable. If this is the case then what
becomes of an Fibre Channel array 10km removed? What makes this more or
less likely to be in driverfs than a IP storage array that is
"physically connected" via gigabit ethernet cable in the next room? If
you where getting at devices which use the IP stack exclusively, then
how do iSCSI HBAs with TCP offload engines fit into the mix? The only
scenario where I see the above statement holding true is if one was to
use iSCSI over a wireless/radio link, then it most definitely could NOT
be part of driverfs. :)
But seriously, I was not implying that every TCP/UDP service should have
its own directory entry within driverfs or that the IP stack should be
included at all, but rather looking from a wider perspective of how
logical devices not on the machine's bus which _should_ be part of
driverfs will fit into the framework.
>
> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. driverfs
> wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
> should it have to.
I am by no means fimilar with the original intent of driverfs, but what
it appears to be morphing into (one of its uses of course) is a tree for
the user to view a list of all the devices within the system. But again
the notion that only physically connected, and not by network cable
devices have a place in the tree simply does not make sense.
I am all for keeping the tree as tidy as possible, but any block level
storage transport regardless of physical (or non-physical :) connection
deserves a place in driverfs, and will only become more apparent as
storage continues to work itself out onto the network.
>
> Regards -- Andy
>
Nicholas Bellinger
On Mon, 24 Jun 2002 15:18, Nick Bellinger wrote:
> This is a red herring, what exactly is the definition of physically
> hooked up to the computer? In the above context it comes out as being a
> device inside the machine or within close proximity (ie: USB, IEEE 1394,
> etc) and connected by a physical cable. If this is the case then what
> becomes of an Fibre Channel array 10km removed? What makes this more or
> less likely to be in driverfs than a IP storage array that is
> "physically connected" via gigabit ethernet cable in the next room? If
> you where getting at devices which use the IP stack exclusively, then
> how do iSCSI HBAs with TCP offload engines fit into the mix? The only
> scenario where I see the above statement holding true is if one was to
> use iSCSI over a wireless/radio link, then it most definitely could NOT
> be part of driverfs. :)
I think if you are mounting the remote filesystem (or otherwise using it in
some stateful way), then it appears in driverfs at mount time. This is
because it becomes important at that point - you now have a dependency on the
underlying transport (the PCI bus better not be shut down before I get the
dirty pages out over the network card to the storage array).
Brad
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
> Is the device PHYSICALLY hooked up to the computer? If not, it shouldn't be
> in devicefs.
But, it should be in driverfs. I'll let the devicefs people decide what to
do ;)
> The device tree (for which devicefs is the fs representation) was originally
> meant to enable good device power management and configuration. driverfs
> wasn't meant to handle iscsi or tcpip (that is, network) connections, nor
> should it have to.
Both statements are entirely true. driverfs doesn't care about device
types. The only thing the filesystem does is export the kernel data
structures and the relationships between them.
But, those devices are physical devices that the kernel is communicating
with. Which is exactly what the device tree was designed to do.
-pat