On Fri, Nov 19, 2010 at 09:00:42PM +0300, Vladislav Bolkhovitin wrote: > Greg KH, on 11/19/2010 12:46 AM wrote: > > On Fri, Nov 19, 2010 at 12:02:58AM +0300, Vladislav Bolkhovitin wrote: > >> Since nobody objected, Greg, could you consider to ACK SCST SYSFS > >> management interface in /sys/kernel/scst_tgt/, please? Please find the > >> SCST SYSFS ABI documentation file you requested below. > > > > No, sorry, again, you should not be using kobjects, and do not polute > > the main /sys/kernel/ namespace with this. > > Which other namespace should we "polute" then? > > > Use 'struct device' please, that is what it is there for, and is what > > the rest of the kernel is using. And use the rest of the > > driver/bus/device infrastructure as your model will work with it just > > fine. > > Greg, sorry, I don't understand your requirements and, because of this, > we can't go ahead implementing them. Could you explain your position, > please? > > 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). > For instance: > > - struct sgv_pool (/sys/kernel/scst_tgt/sgv/<cache>) is an SG vectors > cache. Isn't it a nonsense to make it device? > > - struct scst_acg > (/sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/) > is an access control group to define which initiators see which LUNs > from target <target>. Same, isn't it a nonsense to make it device? > > - struct scst_acn > (/sys/kernel/scst_tgt/targets/<target_driver>/<target>/ini_groups/<group>/initiators/<initiator_name>) > is an entry in the access control group <group> to define which > initiators should use group <group>. Again, isn't it a nonsense to make > it device? > > Etc. > > How could they fit in the driver/bus/device model? Maybe not all of them are. Some of them could probably be represented by attributes of other devices. And some of them are, fitting into the overall /sys/devices hierarchy and describing physical and logical relations between them. -- Dmitry -- 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
