On Tue, 2009-09-29 at 14:49 +0200, Oliver Neukum wrote:
> I suppose you also want to do this for
>
> - mmc cards
> - firewire
> - external sata
> - pcmcia card readers
Indulge some rambling: "Safely remove hardware" is a bit fuzzy, some
devices have displays that says "Not safe to remove" and "Safe to
remove", some devices with rotating spindles power down the motor, some
turn off the LED. This all depends on the firmware running in the
device. In fact, for most devices, such as the Kindle or the iPod just
doing eject(1) will do what is needed. But for e.g. an optical USB
CD-ROM drive, you don't want this since the tray would be opened. So it
depends.
For other devices, you need a bigger hammer, such as suspending the USB
device. And yet, for others, removing the power from the USB port does
the trick.
There may or may not be mechanisms to do this for other interconnects
and buses. You mention SATA. As far as I can tell, there is no way to
remove power from a SATA port. So that's fine. Maybe we don't offer
"Safely Remove Hardware" control for SATA. Or maybe we do but the device
is still visible on the system. That's probably good enough for the
"Safely Remove Hardware" control on the system.
And then you have SAS. For a SAS drive, maybe we light up the "READY
LED" (which is a SAS-specific feature). Or if the SATA or SAS disk is in
a SES-2 enclosure we light up some of the LEDS defined in SES-2. Which
includes sending SCSI commands to another device in the storage area
network.
The point here is that there's a ton of different things that needs to
be done depending on actual piece of hardware you want to "Safely
Remove" to create a meaningful, useful and consistent user experience. I
don't think putting that into the kernel is at all useful; the kernel
simply doesn't know all that you need to know and a lot of it depends on
configurable policy.
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.
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.
Sorry for the long mail.
David
--
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
