Re: Devd event from GEOM?

On Sun, 30 Jan 2005, Alexander Leidinger wrote:

> While you are talking about it and tossing out ideas... do you also
> think about what to do when the hardware in question is supposed to go
> away? 
> 
> Let's take a CD for example, when it arrives the auto-mounter mounts it. 
> Fine, but the CD is locked then. What do we do when we want to remove
> the CD? Or another example, an USB stick. The hardware isn't locked, but
> when we just remove it, we're calling for a kernel panic. 

One of the "big missing events" we need to do desktop automounting easily
and correctly is the "eject request" event.  automounted needs to learn
that the user has requested an eject of the CD, and that it should go out
an unmount the file system, and then issue the software eject and/or allow
the user to be notified.  Note that there are at least two interesting
sources of eject requests: hardware that has a soft eject mechanism, and
software that indicates the user intent to perform a hard eject.  Examples
would be the eject button on your CDROM drive, and the little XP applet
that allows you to tell the OS you're done with your USB keychain.

It strikes me that devd and its event mechanism are good places for those
events to end up, but how they get passed around in the kernel is an
interesting question.  Where do we find soft eject buttons today, and how
do they relate to the hardware they effect?  On a CDROM drive, presumably
we get an ATAPI event of some sort (or maybe we poll for it?) so there's a
clear relationship between the device that will perform the eject and the
event source.  In this scenario, you could imagine GEOM providing an event
mechanism to notify for eject requests so GEOM classes could act on that
request, and/or pass it on.  But for stuff like removable PCI hardware,
etc, I don't know what the hardware capabilities are, or the requirements.
This all relates closely to the quiesce behavior in newbus, so the kernel
mechanisms that represent this stuff may differ a lot, even if we want to
make it look somewhat the same to the user.

Note that one of the quite neat things about XP's eject tool is that it
appears to do a decent job of identifying the implications of a
user-requested eject: it shows you the bus the device is on, the device
itself, that it provides a storage service, and what file system is
mounted on it when it says "are you sure".  That level of inter-layer
integration, even if only a veneer on top, is desirable (and also hard).

Robert N M Watson