> From: David Brownell [mailto:[email protected]]
> > 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 http://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
> It's a matter of where to draw the line. Obviously when we're talking
> physical devices, my tcpip connection to http://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.
That is rather confusing with respect to 1394. You should log out of sbp2
devices, but they can still be shared. Basically 1394 is shared though, and
other types of device dont have logins. So you should probably exclude it.
But anything with disks on at least wants the device flushed before sleeping,
and probably unmounted in many cases.
Justin
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
> > 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 http://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 http://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
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