On Sat, 8 Nov 2003, Stephane Galles wrote: > As a developper I agree Alan. > > But IMHO, as a user of the usb-storage driver, I think that something is > missing here. > > As a user I expect the usb-storage driver to handle the whole process of > intializing my > USB Mass storage peripheral. And if something goes wrong I want to be > informed in a meaningfull way by this driver.
It's an odd sharing of responsibility, to be sure. > In checking if the device has been detected, the usb-storage driver > could log something saying > 'too bad... your device can not be handled, it could not be initialized, > this must be a non standard > USB mass storage...' or anything like that. Adding such a message wouldn't hurt. > For now, when the INQUIRY fails, there isn't any error message. > Someone that has already used a working usb mass storage device will > know that something > goes wrong coz the SCSI information messages are missing (sda1 creation, > etc...) > Someone that does not know what the 'nominal' logs look like will only > see the final message that says : > 'USB Mass Storage support registered' and will think that his USB Mass > Storage support > is fully functionnal. > This message only means that the the SCSI Virtual Host for USB Mass > Storage is fully functionnal. > Well, why not, but it may too complicated a concept for a user that does > not know how > the usb-storage driver is implemented. > > And to go a step further, when the INQUIRY fails why not unregister, > the usb-storage device and clean everything (SCSI Virtual Host, etc...) > What's the point in keeping a /proc/scsi/usb-storage entry that is useless ? > The periperal is broken after all. But I'm surely missing things that > prevent us from doing this, > as I don't have a full understanding of the USB layer. We could do that; there's nothing preventing it. But I don't think it would be to anyone's advantage. Keeping an apparently-useless /proc/scsi/usb-storage entry doesn't _hurt_ anything, and it can help in testing and debugging. > Anyway, I must say that I don't even know how I would get the > information that the SCSI > device was registered. Maybe with the slave_configure callback that is > called when > the scsi_scan succeds ? Ouch, it would not be neat... I'm clueless... No, it's simpler than that. After calling scsi_scan_host() we can simply look to see if any devices are registered under the host -- it's just a question of whether or not a certain list is empty. > >A better, more general solution would be to have usb-storage automatically > >check the result from every INQUIRY command -- or at least from the first > >INQUIRY command sent to each new device. Depending on how it fails, > >usb-storage could set the FIX_INQUIRY flag and then make up its usual fake > >response. That would remove the need to have a special entry in > >unusual_devs.h, which would be a Good Thing since lots of USB devices > >share this particular flaw. > > > > > Great ! unusual_devs.h would be smaller. Good thing. My camera would > work out of the box (it actually is its only flaw). That certainly is doable. The only question is: which sorts of errors in an INQUIRY indicate that the fake response is needed and which sorts of errors indicate there really is a broken device? Or even none at all -- with some protocols the device doesn't tell us how many LUNs it has, and the only way to find out is by probing all of them and seeing which ones respond. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
