Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753361Ab1F2CqS (ORCPT ); Tue, 28 Jun 2011 22:46:18 -0400 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]:55313 "EHLO qmta02.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616Ab1F2CqM (ORCPT ); Tue, 28 Jun 2011 22:46:12 -0400 Date: Tue, 28 Jun 2011 19:45:28 -0700 From: matt mooney To: David Chang Cc: Greg KH , N?meth M?rton , Greg Kroah-Hartman , Kulikov Vasiliy , Endre Kollar , Arjan Mels , Ilia Mirkin , Himanshu Chauhan , Max Vozeler , Arnd Bergmann , usbip-devel@lists.sourceforge.net, devel@driverdev.osuosl.org, LKML Subject: Re: [PATCH] usbip: handle length at sysfs show() functions Message-ID: <20110629024528.GA37164@haskell.muteddisk.com> Mail-Followup-To: David Chang , Greg KH , N?meth M?rton , Greg Kroah-Hartman , Kulikov Vasiliy , Endre Kollar , Arjan Mels , Ilia Mirkin , Himanshu Chauhan , Max Vozeler , Arnd Bergmann , usbip-devel@lists.sourceforge.net, devel@driverdev.osuosl.org, LKML References: <4DE5CA9F.6010303@freemail.hu> <20110607213418.GB11102@kroah.com> <4DEF0822.7070500@freemail.hu> <20110608160931.GB21645@kroah.com> <4DEFE938.70408@freemail.hu> <20110608221655.GA27576@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5421 Lines: 148 On 18:28 Mon 27 Jun , David Chang wrote: > Hi, > > 2011/6/9 Greg KH > > > 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@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/