Re: Devd event from GEOM?

From: Alexander Leidinger <Alexander_at_Leidinger.net>
Date: Sun, 30 Jan 2005 16:13:23 +0100
On Tue, 25 Jan 2005 17:01:27 +0000 (GMT)
Robert Watson <rwatson_at_freebsd.org> wrote:

> A simple auto-mounter simply watches for every storage device that arrives
> via GEOM, checks to see if it's leaf class, and if it is, tastes for a
> file system header, auto-detecting some of the simple and common types,
> such as FAT, UFS, UFS2, cd9660.  It can then use whatever logic it
> pleases, probably partly from a config file, to decide where to mount it,
> what security parameters to use, etc.  Here-in lies the key:  because devd
> says "a storage device, /dev/ad0s1a arrived", it knows it can just go
> ahead and taste, not worrying about rewinding the tape, reading from
> kernel memory, etc.  The auto-mounter specifically wants to hear only
> about GEOMs.

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.

So we can't talk about a "simple" auto-mounter (device appears -> mount
it). And as long as we don't talk about a "not-so-simple" auto-mounter
(one which knows about how to interact with non-root users -- perhaps in
a safe manner, whatever this means ATM) we don't need to talk about such
arrival events, since we need user interaction to remove the devices
anyway (when you need to umount the device by hand, it's not that much
more effort to mount it in the first place).

Bye,
Alexander.

-- 
                           Reboot America.

http://www.Leidinger.net                       Alexander _at_ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
Received on Sun Jan 30 2005 - 14:14:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:27 UTC