Am Dienstag, 29. September 2009 20:09:23 schrieb David Zeuthen: > This is especially true if you are aiming for a generic API. And, note, > I'm _not_ aiming at a very generic API. I want this for a daemon that > only handles disks. And that's good, it means I can create a really good > user experience around it - I mean, lighting LEDS on enclosures, > powering down USB ports, all that good stuff. I would have never thought that safely removing a device is that hard. > However to do this, the mechanism that is the kernel needs to expose > functionality to do what I want. In this case, it's the "remove power > from USB port" thing. Sure, can people abuse this feature in the kernel? > Of course. But giving people rope is hardly something new. That's why > you need to be uid 0 to do this - whereas to use the DriveDetach() > method on my daemon, you need only to be e.g. a local user on the > console. I have no problem with exporting this feature at all. It is necessary for what you want to do and what you want to do is useful. My problem is with the API to user space. I suggest that you add this to the storage driver not generic USB code and all is well. You could even make an API that makes the storage driver unregister the SCSI host but retain its binding to the device until it tells usbcore to disable the port. That closes the race with probe(). Can you live with that? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
