Date: Mon, 03 Feb 2003 17:47:52 -0200 From: "Daniel C. Sobral" <dcs@tcoip.com.br> To: "M. Warner Losh" <imp@bsdimp.com> Cc: rwatson@FreeBSD.ORG, ob@e-Gitt.NET, freebsd-current@FreeBSD.ORG Subject: Re: Question about devd concept Message-ID: <3E3EC768.7030707@tcoip.com.br> In-Reply-To: <20030202.112911.101834304.imp@bsdimp.com> References: <20030202165352.GA6957@e-Gitt.NET> <Pine.NEB.3.96L.1030202121638.63806L-100000@fledge.watson.org> <20030202.112911.101834304.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote:
> 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...
I think people are coming at this from the wrong direction. The scripts
in /etc/rc.d ought to deal with setting up dhclient and whatever else
correctly if the device is present (rc.conf settings not precluding
this). I think, rather, that it is devd which should call rc.d to do
things at device arrival, _after_ bootstrap has completed.
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
Daniel.Sobral@tcoip.com.br
dcs@tcoip.com.br
Outros:
dcs@newsguy.com
dcs@freebsd.org
capo@notorious.bsdconspiracy.net
The most interesting specimen will not be labeled.
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?3E3EC768.7030707>