Re: [PATCH] usbip: handle length at sysfs show() functions

[Greg KH <greg@kroah.com>]

On Wed, Jun 08, 2011 at 07:26:58AM +0200, Németh Márton wrote:
> Greg KH wrote:
> > On Wed, Jun 01, 2011 at 07:14:07AM +0200, Németh Márton wrote:
> >> The sysfs show() functions shall return the actual content length of
> >> the result buffer. According to Documentation/filesystems/sysfs.txt:215
> >> the scnprintf() function is preferred.
> >>
> >> See also the article titled "snprintf() confusion" at
> >> http://lwn.net/Articles/69419/ .
> >
> > [...]
> >
> > Here we are doing lots of work to try to put more than one value in the
> > sysfs file, and return the proper data to the kernel about how big the
> > buffer we used.
> > 
> > That's wrong, and violates the "one value per file" sysfs rule, so that
> > should be fixed instead of trying to change the sprintf() call.
> 
> As I understand there is a need to change the design here. Currently I
> get the following content when vhci-hcd is loaded but not yet used:
> 
> $ cat /sys/devices/platform/vhci_hcd/status
> prt sta spd bus dev socket           local_busid
> 000 004 000 000 000 0000000000000000 0-0
> 001 004 000 000 000 0000000000000000 0-0
> 002 004 000 000 000 0000000000000000 0-0
> 003 004 000 000 000 0000000000000000 0-0
> 004 004 000 000 000 0000000000000000 0-0
> 005 004 000 000 000 0000000000000000 0-0
> 006 004 000 000 000 0000000000000000 0-0
> 007 004 000 000 000 0000000000000000 0-0
> 
> The fields are: port, status, speed, device ID, socket pointer and
> local busid name. This is too complex for sysfs. Maybe we could extend
> the devices file of usbfs with some new rows?

Ick, I doubt it as there are lots of tools that parse that file already.

But yes, you are correct, this should not be in sysfs at all.

What's the use for this file?  Who uses it?  Is it just debugging
output?  Information for people to gaze at if they feel like it?
Something else?

Once we figure that out, then we can determine where it should go
(debugfs, sysfs in a different file format, usbfs, etc.)

thanks,

greg k-h