On Thu, 2008-08-28 at 21:52 +0400, Vladislav Bolkhovitin wrote: > >> So, I believe, a configuration interface should be rather /proc or /sys > >> interface based. I don't think we should care much about backward > >> compatibility with tgtadm, because the existing interface doesn't reach > >> the state of being widely used. > > > > I would definately vote against proc here for the fancy stuff I > > mentioned above. I have experience enabled core-iscsi to use sysfs for > > RO data, but nothing along the lines of what would be required for a > > generic target mode RW control path. Does anyone with sysfs experience > > have any comments on thing..? > > Sysfs as well as configfs have one big disadvantage. They limit each > file to only 4KB. This would force us for to create a subdirectory for > each device and for each connected initiator. I don't like seeing > thousands subdirectories. Additionally, such layout is a lot less > convenient for parsing for the high level configuration tool, which > needs to find out the difference between the current configuration and > content of the corresponding config file. That's because each of those interfaces is designed around one value per file. > Currently, with procfs SCST can list in /proc/scst/sessions virtually > unlimited amount of connected initiators in a simple for parsing manner. > It was done using seq interface well and simply. Neither sysfs, nor > configfs support seq interface. This would introduce significant effort > in both kernel and user spaces. > > Debugfs supports seq interface, but, because of the name, I doubt we can > use it ;) > > Thus, looks like we'd better stay with /proc. After all, networking and > VM widely use /proc for internal configuration. Why SCSI target is worse? I wouldn't do that. /proc has been deprecated for several years for large config interfaces (indeed it's trying to be scaled back only to deal with processes). Nothing with a huge /proc interface would pass a review for 2.6 nowadays. James -- 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
