Dmitry Torokhov, on 11/19/2010 11:22 PM wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
