driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Grover, Andrew]

> From: Nick Bellinger [mailto:nickb@attheoffice.org] 
> 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

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[David Brownell]

> 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

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Nick Bellinger]

On Sun, 2002-06-23 at 16:59, Grover, Andrew wrote:
> > From: Nick Bellinger [mailto:nickb@attheoffice.org] 
> > 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

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Brad Hards]

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.

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map)

[Patrick Mochel]

> 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

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: David Brownell [mailto:david-b@pacbell.net] 
> > 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".

Yep I meant driverfs. Oops.

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

It's a matter of where to draw the line. Obviously when we're talking
physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
port is. I actually think keeping in mind that driverfs is for power
management can help delineate what should be in driverfs and what shouldn't.
With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
but the main question should be:

"If my computer suspends, should this device be turned off?" Which is
another way of asking is the use of a device exclusive to a particular
machine.

If a device can be accessed by multiple machines concurrently, it should not
be in driverfs.

> No, of course driverfs isn't for everything.  But if it's not 
> for all drivers,
> then what's it for -- just power management?

"Just" power management??? Like power management isn't important enough???
;-)

We need a device tree to do PM. If driverfs's PM capabilities are hurt
because it doesn't stay true to that, then the featureitis has gone too far.

Regards -- Andy

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[David Brownell]

>>No, of course driverfs isn't for everything.  But if it's not 
>>for all drivers,
>>then what's it for -- just power management?
>  
> "Just" power management??? Like power management isn't important enough???
> ;-)

Well, it's only one of the roles I'd expect of a "driver filesystem",
and actually no -- not the most important one.  If instead it were
called "powermanagementfs" ... or if it were renamed to that ... :)


> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone too far.

And for other reasons, we also need one.  I don't think you've actually
pointed out any concrete problems for PM though.

- Dave

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[James Bottomley]

andrew.grover@intel.com said:
> If a device can be accessed by multiple machines concurrently, it
> should not be in driverfs. 

On that argument, we'll eliminate almost all Fibre Channel devices!

I think the qualification for appearing in driverfs is actually possessing a 
driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
FileSystems are debatable, but not anything which has a real device driver.

> We need a device tree to do PM. If driverfs's PM capabilities are hurt
> because it doesn't stay true to that, then the featureitis has gone
> too far. 

Perhaps it's more a question of whether power management belongs as an every 
unit item in driverfs.  As you say, we get problems where the device is shared 
between multiple computers.

James

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, James Bottomley wrote:

> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs.
>
> On that argument, we'll eliminate almost all Fibre Channel devices!
>
> I think the qualification for appearing in driverfs is actually possessing a
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as
> FileSystems are debatable, but not anything which has a real device driver.

Between iSCSI and filesystems there's still MD, loopback, ramdisk, NBD,
LVM, and general partitioning. They all expose block devices and try their
damnedest to look like physical devices. If we're serious about using
driverfs as a system for unifying device detection ("show me all my disks,
please"), then these should all be in too.

And they raise some interesting problems. As pointed out earlier, iSCSI is
potentially multipath, as is LVM, NBD, and software RAID. Hardware RAID is
already multipath in some cases so our tree really ought to be a DAG.

And let's think about loopback a moment. It's potentially layered on top
of a filesystem, layered on top of a logical volume layered on top of SCSI
and ATA. Just from the power management perspective, to quiesce our
system, we'll have to know that we need to flush loop->fs->lvm->scsi/ata
before we can shut down whichever drive.

So to be done right, we need to pull filesystems into the tree too (rather
than just implicitly correlating against /proc/mounts).

> > We need a device tree to do PM. If driverfs's PM capabilities are hurt
> > because it doesn't stay true to that, then the featureitis has gone
> > too far.
>
> Perhaps it's more a question of whether power management belongs as an every
> unit item in driverfs.  As you say, we get problems where the device is shared
> between multiple computers.

And we already have a problem there for local SCSI - see OpenGFS which
lets you share a filesystem on a single SCSI bus. Admittedly, that's
rather sick, but not as appalling for FC, iSCSI, or NBD (or GFS's
internal equivalent).

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> I think the qualification for appearing in driverfs is actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real device driver.

The qualification for appearing in the device tree is the physical 
presence of the device, regardless of the presence of a driver to control 
it. (This typically depends on the presence of the bus driver so it can 
discover the device.) Presence in the device tree implies presence in 
driverfs.

	-pat

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Roman Zippel]

Hi,

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:
>
> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
>
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

I don't think it's that easy. If the computer wakes up again, devices have
to be reinitialised in the right order, e.g. iSCSI needs a working network
stack and devices. Another problem is how to properly shutdown the
machine. Scripts now "know" that nfs requires the network, but how does
the script find out, that /dev/sdb2 is an iSCSI device, so that it can
properly unmount the device, before the network is shutdown?

bye, Roman

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[John Summerfield]

> 
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2

I'm far from expert here, but isn't the network card important here?


> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.
> 

Back in the 1970s I used a computer where disk drives, tape drives and RAM 
chould be physically connected to and used by more than one computer at once.

It was an IBM S/370 model 168 MP; you might argue the toss on the RAM, but the 
disk drives were beyond argument.


On which devices should MVS have ignored power cycling?
-- 
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my disposition.

==============================
If you don't like being told you're wrong,
	be right!

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Patrick Mochel]

> > 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.
> 
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to www.yahoo.com is not one. My PS/2
> port is. I actually think keeping in mind that driverfs is for power
> management can help delineate what should be in driverfs and what shouldn't.
> With technologies like USB, infiniband, NFS, iSCSI, and 1394, it's tough,
> but the main question should be:

When you're talking to www.yahoo.com, you're really only talking to the 
webserver. Sure, indirectly you're talking to their network card, their 
disk, their memory, and their cpu. But, let's not get carried away. 

With things like network block devices, you're communicating directly with 
a device. (Yes, it may be a virtual device that doesn't have a mapping to 
a real physical device. But it doesn't matter; you _think_ it's a device.)

driverfs is not power management. driverfs does not care about power 
management. The device model is not about power management. Power 
management is one benefit of having a unified device tree, but it is not 
it's main focus. It's purpose is to represent the physical layout of 
devices in the system as accurately as possible. 

> "If my computer suspends, should this device be turned off?" Which is
> another way of asking is the use of a device exclusive to a particular
> machine.
> 
> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

So, what about network cards? Disks with partitions exported via NFS? 
Serial ports with a null modem attached? 

Sound absurd? Of course it does, but in it lies the distinction between 
devices you care about and devices you don't: if it's local, you suspend 
it. If it's not, then you don't power it down. The drivers for these 
devices should be able to tell whether you're communicating with a local 
or remote device and choose the appropriate action. 

	-pat

Re: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Pavel Machek]

Hi!

> If a device can be accessed by multiple machines concurrently, it should not
> be in driverfs.

You can access scsi disk from 2 machines simultaneously. Its just not
a common case. I believe we still want scsi in driverfs ;-).
									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

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
> andrew.grover@intel.com said:
> > If a device can be accessed by multiple machines concurrently, it
> > should not be in driverfs. 
> 
> On that argument, we'll eliminate almost all Fibre Channel devices!
> 
> I think the qualification for appearing in driverfs is 
> actually possessing a 
> driver.  Therefore, we accept FC and iSCSI.  Things which appear as 
> FileSystems are debatable, but not anything which has a real 
> device driver.

OK that makes sense.

Regards -- Andy

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Grover, Andrew]

> From: Roman Zippel [mailto:zippel@linux-m68k.org] 
> On Mon, 24 Jun 2002, Grover, Andrew wrote:
> > If a device can be accessed by multiple machines 
> concurrently, it should not
> > be in driverfs.
> 
> I don't think it's that easy. If the computer wakes up again, 
> devices have
> to be reinitialised in the right order, e.g. iSCSI needs a 
> working network
> stack and devices.

Would the iSCSI device be a child of the network device? That would ensure
that the NIC was fully restarted before the iSCSI device.

> Another problem is how to properly shutdown the
> machine. Scripts now "know" that nfs requires the network, 
> but how does
> the script find out, that /dev/sdb2 is an iSCSI device, so that it can
> properly unmount the device, before the network is shutdown?

Would a bottom-up traversal of the device tree do things properly?

Regards -- Andy

RE: driverfs is not for everything! (was: [PATCH] /proc/scsi/map )

[Oliver Xymoron]

On Mon, 24 Jun 2002, Grover, Andrew wrote:

> > From: Roman Zippel [mailto:zippel@linux-m68k.org]
> > On Mon, 24 Jun 2002, Grover, Andrew wrote:
> > > If a device can be accessed by multiple machines
> > concurrently, it should not
> > > be in driverfs.
> >
> > I don't think it's that easy. If the computer wakes up again,
> > devices have
> > to be reinitialised in the right order, e.g. iSCSI needs a
> > working network
> > stack and devices.
>
> Would the iSCSI device be a child of the network device? That would ensure
> that the NIC was fully restarted before the iSCSI device.

If by network device you mean NIC, the answer is no. Think redundant
routing. This problem already exists in the SCSI realm (multipathed
arrays) and there's I remember reading there's some multipath stuff in
place, but I doubt driverfs has really thought about it.

The multipath problem means our tree is really a DAG. Which may or may not
be a problem.

> > Another problem is how to properly shutdown the
> > machine. Scripts now "know" that nfs requires the network,
> > but how does
> > the script find out, that /dev/sdb2 is an iSCSI device, so that it can
> > properly unmount the device, before the network is shutdown?
>
> Would a bottom-up traversal of the device tree do things properly?

If we think in terms of DAGs instead of trees, yes.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."