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>