3. Address of the current scsi_cmnd block (if any).
Is the actual address at all useful?
What's important is "which request", and the pointer serves as a good enough ID in most contexts. Especially if this code ever starts to queue more than one request at a time.
4. Count values for various semaphores/completions: device in use, awaken control thread, wait for abort to complete.
Sounds right. Perhaps also listing any device quirks.
5. There's a handful of flags that could be listed. That information should really be made available through the /proc/scsi/usb interface. Maybe you feel that the entire /proc/scsi/usb thing should be moved to sysfs anyhow.
Maybe, but it wasn't providing this kind of info last time I looked. Just some info about the devices, not about driver state.
What is the proper format for putting this stuff into sysfs? Should every item get its own file? Or should common items go in the same file, maybe yielding 4 or 5 files containing the information as listed here? Or one big file with everything (not that much, really)? Bear in mind that this must be read-only; with the driver running it's not possible/safe to change any of these values. And of course much of it is volatile, constantly changing as the driver runs.
I for the pragmatic approach, where reading the contents of the debug file is just a "spinlock, sprintf everything, unlock". One "Big" (1KB?) file is easiest to use when debugging, since only that approach provides a consistent snapshot.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
