public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Németh Márton" <nm127@freemail.hu>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
	Matt Mooney <mfm@muteddisk.com>,
	Kulikov Vasiliy <segooon@gmail.com>,
	Endre Kollar <taxy443@gmail.com>, Arjan Mels <arjan.mels@gmx.net>,
	Ilia Mirkin <imirkin@alum.mit.edu>,
	David Chang <dchang@novell.com>,
	Himanshu Chauhan <hschauhan@nulltrace.org>,
	Max Vozeler <max@vozeler.com>, Arnd Bergmann <arnd@arndb.de>,
	usbip-devel@lists.sourceforge.net, devel@driverdev.osuosl.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usbip: handle length at sysfs show() functions
Date: Wed, 8 Jun 2011 15:16:55 -0700	[thread overview]
Message-ID: <20110608221655.GA27576@kroah.com> (raw)
In-Reply-To: <4DEFE938.70408@freemail.hu>

On Wed, Jun 08, 2011 at 11:27:20PM +0200, Németh Márton wrote:
> > Ick, I doubt it as there are lots of tools that parse that file already.
> 
> usbip is still part of the staging directory. In dmesg the following appear:
> 
> | usbip_common_mod: module is from the staging directory, the quality is unknown, you have been warned.
> | usbip_common_mod: usbip common driver1.0
> | vhci_hcd: module is from the staging directory, the quality is unknown, you have been warned.
> 
> so this means that usbip is a work-in-progress, it might be changed anytime. On
> the other hand we can do this nice way: a new entry in  Documentation/feature-removal-schedule.txt
> for /sys/devices/platform/vhci_hcd/status file removal, let's say it will be
> removed before the usbip goes to mainline. In parallel the new interface
> can be developed.

Or we can just fix it properly, as we have the userspace tools in the
kernel now as well, and the interface is obviously broken.  That's what
being in the staging tree allows us to do.

> > 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?
> 
> Based on the user space source code at drivers/staging/usbip/userspace/
> I can identify the following usages:
> 
> libsrc/vhci_driver.c::get_nports():
>  - finding out how many ports the VHCI has

Is that really necessary as they are just "virtual" ports :)
We can put that in a single sysfs file if needed.

> libsrc/vhci_driver.c::parse_status():
>  - VHCI port number to identify virtual ports
>  - fetching the status of each VHCI ports whether it is
>      - vdev does not connect a remote device: (status = VDEV_ST_NULL = 4):
>        "Port Available"
>      - vdev is used, but the USB address is not assigned yet (status =
>        VDEV_ST_NOTASSIGNED = 5): "Port Initializing"
>      - used (status = VDEV_ST_USED = 6): "Port in Use"
>      - error (VDEV_ST_ERROR = 7): "Port Error"
>  - the speed can be unknown/low/full/high/variable
>  - it looks like the bus column was merged with the device column but I
>    currently cannot find when
>  - the device ID is splited to the upper 16bits: bus number, and lower
>    16bits: device number
>  - based on local_busid the usb device file can be found in /sys using
>    sysfs_open_device()

All of those can be placed in individual files under the different port
directories, so we should be fine.

> Note that the socket parameter is only printed out as a debug information: it
> is not used anywhere.
> 
> Maybe most of the file content is redundant, because:
> 
>  - we have /sys/bus/usb/devices/usb*/maxchild which is "number of ports if hub"
>    according to linux/usb.h:410 ;

Yes.

>  - we have /sys/bus/usb/devices/*-*/speed to identify the device speed;

Yes.

>  - We have already bus number at /sys/bus/usb/devices/usb*/busnum or at
>    /sys/bus/usb/devices/*-*/busnum ;

Yes.

>  - we also have /sys/bus/usb/devices/*-*/devnum ;
>  - it is possbile to collect all the devices from /sys/bus/usb/devices/*-*
>    filtering to the first number to /sys/bus/usb/devices/usb*/busnum .
> 
> The only thing which is special for VHCI is the status for each port:
> DEV_ST_NULL/VDEV_ST_NOTASSIGNED/VDEV_ST_USED/VDEV_ST_ERROR .

So we add a status file and we are set.

Anyone care to send patches to fix this all up?

thanks,

greg k-h

  reply	other threads:[~2011-06-08 22:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01  5:14 [PATCH] usbip: handle length at sysfs show() functions Németh Márton
2011-06-07 21:31 ` Greg KH
2011-06-07 21:34 ` Greg KH
2011-06-08  5:26   ` Németh Márton
2011-06-08 16:09     ` Greg KH
2011-06-08 21:27       ` Németh Márton
2011-06-08 22:16         ` Greg KH [this message]
     [not found]           ` <BANLkTikokYys2srX3+5r+fkdaaX5V2zxUg@mail.gmail.com>
2011-06-29  2:45             ` matt mooney
2011-06-29  5:54               ` Németh Márton
2011-06-29 16:20               ` Matt Chen
2011-06-29  2:23         ` matt mooney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110608221655.GA27576@kroah.com \
    --to=greg@kroah.com \
    --cc=arjan.mels@gmx.net \
    --cc=arnd@arndb.de \
    --cc=dchang@novell.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@suse.de \
    --cc=hschauhan@nulltrace.org \
    --cc=imirkin@alum.mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max@vozeler.com \
    --cc=mfm@muteddisk.com \
    --cc=nm127@freemail.hu \
    --cc=segooon@gmail.com \
    --cc=taxy443@gmail.com \
    --cc=usbip-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox