Date: Sun, 02 Feb 2003 11:29:11 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: rwatson@FreeBSD.ORG Cc: ob@e-Gitt.NET, freebsd-current@FreeBSD.ORG Subject: Re: Question about devd concept Message-ID: <20030202.112911.101834304.imp@bsdimp.com> In-Reply-To: <Pine.NEB.3.96L.1030202121638.63806L-100000@fledge.watson.org> References: <20030202165352.GA6957@e-Gitt.NET> <Pine.NEB.3.96L.1030202121638.63806L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.NEB.3.96L.1030202121638.63806L-100000@fledge.watson.org>
Robert Watson <rwatson@FreeBSD.ORG> writes:
: I ran into a similar problem, actually -- programs like dhclient rely on
: being able to write to lease and pid files. It's almost as though we'd
: like an additional set of events when the system is "more booted". I.e.,
: a devd event for each device when the network is started, etc.
That might make sense. Part of the problem is that while the system
is booting there is only some vague notion of system state once you
get to init. Part of the problem also is that devices have no
information about what type of device any given device is. There's no
way that one could "hold in abeyance" those devices that are network
devices because we have no clue what a network device is and what
isn't. It gets muddier when devices have multiple uses. Is sio a
network device? If it is used for a ppp link it is, but if it is used
for a serial console it isn't...
: Actually, I suspect what we want is to have a seperate network event
: management daemon -- arrival of the device is not the same as arrival of
: the interface. dhclient events (and related things) should happen as a
: result of the interface arriving, not the newbus device arrival. I.e., a
: netd that listens to routing socket and kqueue events relating to the
: network stack.
Trouble is that "network interface arrival" is the same as "device
arrival" The network interface is attached in foo_attach() so that's
not a better time to do things because it is the same time. Since it
happens in foo_attach, it actually happens before the device is
entirely attached to the tree, so you are suggesting doing something
that happens earlier :-). While carrier detect might be slightly
better, it still is insufficient because that usually happens before
init is run too. If it was that easy, I'd do it.
I'm still trying to find the best place to start devd. Right now it
starts before everything else. Maybe it needs to start just after the
network starts, but that's arbitrary. That would ensure that we have
a writeable /var for dhclient, but might preclude other interesting
uses for devd. One could also make a case for just before network
starts too. Doing it after means that one only has to put the 'don't
configure it again' check into one place rather than two. The one in
the second place has generated some problem reports that I need to
look into.
Part of the problem too is that we're now doing the configuration of
devices in two places. Network devices are the only ones where we do
interesting things with, but I think that we're seeing growning pains
introducing dynamic things into a formerly static system. It is
little different than when pccard and dynamic device loading was added
to the kernel...
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030202.112911.101834304.imp>