Messages in this thread | | | Date | Fri, 29 Aug 2008 07:39:02 -0700 | From | Greg KH <> | Subject | Re: [PATCH] USB: add USB test and measurement class driver - round 2 |
| |
On Fri, Aug 29, 2008 at 12:57:54AM -0600, stefan_kopp@agilent.com wrote: > Hi all, > > I haven't been able to follow all the enhancements you did to the > driver, but I can comment on the ratioale behind the orignal driver. > > The original driver used minor number 0 for "driver communication" (in > contrast to "device communication"). The main purpose was to get a > list of the USBTMC devices attached by doing a "cat /dev/usbtmc0" > (which would point to minor number 0). The first device found would > then use the next free minor number, usually 1. I believe the concept > of "driver communication" has been removed from the driver, so a > single minor number for a single device should be it.
cating that file was sending out a text file to userspace that needed to be parsed, like a /proc file. Now you can just look at all of the devices in /sys/class/usb/usbtmc* to see all of the different devices in the system.
> The issue with using cat on the shell level is that it uses fread > which has the (in this case) ugly behaviour of recalling the driver's > read method until the full number of characters requested has been > accumulated (or until zero characters are returned, indicating the end > of file). With USBTMC instruments, this behavour is bad because the > retry will not just return zero characters, it will cause a timeout > with the associated error condition in the device. So, to enable the > use of echo/cat, I added some fread handling to the driver (which > catches the retries). I believe this also has been removed, so I > assume cat/fread will not work (?).
I do not know, but we do not do wierd things in the kernel just because of broken userspace programs. This logic should be done in userspace, and programs should look at the return value of read() and handle it properly. Otherwise it is a bug.
thanks,
greg k-h
| |