I see, this makes perfect sense, thanks for all the information! I guess kudzu on Fedora is in need of a major overhaul? Incidentally, the comment about /proc/scsi/scsi vs. /proc/bus/usb/devices was in response to a question I had asked on kudzu bugzilla about this. And yes, I was not suggesting INQUIRY was really broken because of this (hence the quotes :-).
Unfortunately, these days I do not have the "free" time I used to in order to set these things up properly and I'm relying on pre-installed utilities and GUIs (eek! :-) more and more. Sad, but true... :-) For now, I think I'll just keep using the (dated) kudzu with "Generic" added to its rules (and let this slide :-). Not pretty, but it gets the job done anyway... Thanks again!! Spiros On Tue, 2004-08-03 at 10:16, Alan Stern wrote: On Tue, 3 Aug 2004, Spiros Papadimitriou wrote: > > > Yes, oops, my mistake! > > > > It is probably Lexar's fault and this is probably a hideous workaround, > > but appending these to unusual_devs.h seems to do the "trick": > > > > UNUSUAL_DEV( 0x05dc, 0xb013, 0x0000, 0x9999, > > "Lexar Media", > > "JumpDrive Trio", > > US_SC_DEVICE, US_PR_DEVICE, NULL, > > US_FL_FIX_INQUIRY), > > > > UNUSUAL_DEV( 0x05dc, 0xa300, 0x0000, 0x9999, > > "LEXAR MEDIA", > > "JUMPDRIVE2", > > US_SC_DEVICE, US_PR_DEVICE, NULL, > > US_FL_FIX_INQUIRY), > > These entries shouldn't be added. The US_FL_FIX_INQUIRY flag is really > intended for devices that don't support INQUIRY at all. > > > I'm not sure if there are many devices with "broken" (meaning: not > > matching the usb vendor and product strings) INQUIRY responses? Getting > > them to work and automatically appear on the desktop with updfstab would > > be nice. > > There are some; I've seen logs sent in by other users where the INQUIRY > strings don't match the USB strings. It's not clear why you think that > makes the devices "broken" in any way. It's quite possible, for example, > that the USB interface and the drive hardware were made by two different > manufacturers and then assembled and sold as a single unit by an OEM. In > cases like that it makes sense for the two sets of strings to be > different. > > > The problem is that, rom a short discussion on kudzu bugzilla, updfstab > > *has* to use the info in /proc/scsi/scsi, since the info in > > /proc/bus/usb/devices has no information about the block device that the > > USB storage unit is "mapped" to. > > That's not true. For an example of how to perform the mapping > using only the information in /proc/bus/usb/devices plus sysfs, see > this thread: > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109147449719112&w=2 > > Furthermore, all this information is available in hotplug events. The > fstab file could be updated by a hotplug script. > > > Adding UNUSUAL_DEV entries for every such device seems stupid (I'm > > guessing that Windows does not use SCSI INQUIRIES, so vendors do not care > > about that?) and, of course, a pain in the behind. > > Not to mention that it completely prevents programs from retrieving the > actual INQUIRY data from the device. Some programs might be interested in > other parts of the data besides the strings, but they wouldn't be able to > get at it. > > > Would it make sense at all to str(n)cmp the USB vendor and product strings > > with the appropriate parts of the device's own INQUIRY response and > > "patch" the inquiry response if they do not match? This should > > "automatically" take care of situations like this, but I have absolutely > > no idea if it breaks other things... > > No, it doesn't make sense. A driver is supposed to do its best to ferry > data back and forth between programs and devices. It's not supposed to > change the data just because some programs don't like what they get. > > Also, the INQUIRY string fields are generally shorter than the USB > strings. So the strings would have to be truncated and still wouldn't > match the way you want. > > Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
