> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:09 EST