Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Sep 2003 14:18:54 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: devd limitations / automounting removable storage
Message-ID:  <Pine.NEB.3.96L.1030918141648.1604D-100000@fledge.watson.org>
In-Reply-To: <20030918.121507.32721201.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 18 Sep 2003, M. Warner Losh wrote:

> In message: <Pine.NEB.3.96L.1030918104650.60612B-100000@fledge.watson.org>
>             Robert Watson <rwatson@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. 

> I worry about putting these new event streams at the wrong level and/or
> having too many of them making it hard to know what the appropriate
> level/event to do something at is.

Agreed.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030918141648.1604D-100000>