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

[Matt Chen]

Hi Matt,
So you are working on "usbip port" command now ?
Because I found no way to look up any port which is bound to remote
device in usbip command.

2011/6/29 matt mooney <mfm@xxxxxxxxxxxxx>:
> On 18:28 Mon 27 Jun     , David Chang wrote:
>> Hi,
>>
>> 2011/6/9 Greg KH <greg@xxxxxxxxx>
>>
>> > 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.
>> >
>>
>> I would like to help on this. :)
>>
>> And I just want to make sure that I understand your discussion.
>>
>> 1. remove current port status table file (
>> /sys/devices/platform/vhci_hcd/status )
>> 2. create each port in path "/sys/devices/platform/vhci-hcd" as a directory
>> ( /sys/devices/platform/vhci_hcd/ports/[0][0-7] )
>> 3. put the port info/status files into each port directory (
>> /sys/devices/platform/vhci_hcd/ports/*/status )
>>
>> Any suggestions are welcome, thanks!
>>
>
> I think it seems like ../ports/.. is unnecessary. We should use
> ../vhci_hcd/*-*/status as suggested by Nemeth. I do believe that we will
> probably need to encode the vhci-hcd port number in there somewhere to allow
> remote devices on different machines but same busid to be imported.
>
> Nemeth are you already working on this?
>
> I need to add the `usbip port' command. I will add a template with some basic
> functionality but will wait on the actual port access.
>
> -mfm
>
>> Regards,
>> David Chang
>>
>>
>> >
>> > > 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
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majordomo@xxxxxxxxxxxxxxx
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at  http://www.tux.org/lkml/
>> >
> _______________________________________________
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxx
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>



-- 
Thanks ~
Matt Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/