Date: Thu, 18 Sep 2003 06:52:59 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: rwatson@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: devd limitations / automounting removable storage Message-ID: <20030918.065259.112623652.imp@bsdimp.com> In-Reply-To: <Pine.NEB.3.96L.1030917161519.51283B-100000@fledge.watson.org> References: <30912.1063828673@critter.freebsd.dk> <Pine.NEB.3.96L.1030917161519.51283B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.NEB.3.96L.1030917161519.51283B-100000@fledge.watson.org>
Robert Watson <rwatson@freebsd.org> writes:
: We might skip the devfs layer since it's probably implicit in the
: completion of ifnet_attach() and disk_create(), but it's worth thinking
: about.
The thing about implicit stuff is that it move knowledge about what is
created in the driver into userland. This isn't necessarily a good
thing. For most of the examples talked about, this isn't an issue,
but what about stranger hardware that creates many devices?
: This would allow ifconfig commands to be issued once the network
: device is available, rather than once newbus has attached an xl0.
network interfaces are available for all drivers in the tree after
attach finishes. However, interfaces that aren't an exact mirror of
the hardware don't show up. tun0, for example.
Also, network interfaces are in a different namespace than newbus
device names.
: Or for
: geom to announce ad0s1e even though newbus doesn't know about it.
Be careful here. You are confusing two different name spaces. dev_t
is a third namespace in the kernel. sysctl is another one and of
course file systems.
You'd want to know that devfs events have happened in this case. GEOM
likely doesn't need to get into the mix. And you can likely do that
with a kqueue on the /dev directory.
GEOM lives in the dev_t name space (right?)
: Or for
: devd to handle the introduction of synthetic interfaces such as vlan, tun,
: etc, which aren't visible to newbus. Or for the device driver names and
: interface names to differ (or for a non-one-one mapping, interface
: renames, etc).
Yes. devd started out life as a device_t only thing. However, it is
better viewed as more generalized event dispatcher that currently only
understand events from device_t entities.
I was going to point out that there's not a connection between the
device_t name and the dev_t name, except by convention. Even when
there is a connection, it can be weird. Device foo0 might create
/dev/foo0_error and /dev/foo0_data, or other such perverse things.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030918.065259.112623652.imp>