In message: <[EMAIL PROTECTED]> Robert Watson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message