devd limitations / automounting removable storage

[M. Warner Losh]

In message: <Pine.NEB.3.96L.1030918141648.1604D-100000 at fledge.watson.org>
            Robert Watson <rwatson at freebsd.org> writes:
: 
: On Thu, 18 Sep 2003, M. Warner Losh wrote:
: 
: > In message: <Pine.NEB.3.96L.1030918104650.60612B-100000 at fledge.watson.org>
: >             Robert Watson <rwatson at freebsd.org> writes:
: > : For ifnet events, we can use routing sockets.  I don't know that we have
: > : GEOM events as yet.  One reason to separately handle GEOM from devfs would
: > : be that GEOM "objects" tend to be storage devices or related notions,
: > : whereas devfs entries could be any number of things.
: > 
: > While this is true, one can ask a /dev entry what kind of object it is. 
: > Since one can do that, one can construct filters that will only do
: > things for storage objects. 
: 
: Opening a device to ask it what it might be is generally a bad idea -- you
: can block other consumers from using the device (and related devices),
: cause a variety side-effects, etc.  Also, I'm not clear that you can get a
: useful result using open/fstat/stat/ioctl to figure out what something is
: without apriori knowledge of device numbers, and even then the utility is
: limited.  If you have a network layer announcement "Hey, this interface
: arrived", then there's no question that it's a network interface. 

You don't need to open the device to know what it is in many cases.
You know you have a potential mount point with a simple stat of the
device.  If you open the device, there's nothing more than you can
learn from it than you can from stat, unless you go the "I'm going to
try this non-destrictuve ioctl and hope for the best" approach.  Tape
drives are a big category of side effects from open.  Few other
devices have any meaningful side effects from opening them, but they
do exist.

Warner