Re: Kernel Level Generic Target Mode control path

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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