Dmitry Torokhov, on 11/19/2010 11:22 PM wrote:
quoted text
>> None of the SCST objects are Linux devices. None of them has entries in
>> /dev, none of them needs to send any events to udev and none of them
>> sends or receives data from DMA, hence has any DMA parameters or
>> restrictions. So, how can them fit into the driver/bus/device model you
>> are enforcing?
> 
> Note that the entities in /sys/devices/... tree and not necessarily
> physical devices bit rather interface abstractionss. Consider, for
> example, /sys/class/input/*. None of the "devices" there talk directly
> to hardware, do DMA or other things. Some of them don't even talk to
> usrespace directly but rather through additional interfaces (evdev.
> mousedev, ect). Still they are represented there and even have suspend
> and resume methods (because even for logical devices it makes sense to
> save and restore some state).

But all of them still place from where to events received and where
requests from Linux sent, aren't them?

SCST devices are not even logical devices. As I wrote, "devices" word is
misleading. SCST devices are converse of what Linux means under this
word. SCST devices are like NFS exports: a place where those events
generated and those requests received.

Think of SCST device as if it sits on the opposite side of the PCI bus
of the corresponding SCSI device Linux sees in /sys/class and /sys/bus.

So, if we need Linux devices for SCST devices, we create them using
scst_local driver. And then, of course, all them have their place in
/sys/class/ and /sys/bus. Although more common use of them from remote
systems via iSCSI, Fibre Channel, InfiniBand, etc. The remote systems
create devices in /sys/class/ and /sys/bus (if they are Linux), we serve
them.

Vlad
--
unsubscribe notice
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/