Peter Jones (pjones@xxxxxxxxxx) said: > On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote: > > Are people against attempting to move to some kind of enhanced init > > system that includes dependencies? Or is that already the plan? > > I think this is still a kindof crappy solution. Many of the cases why > "dependencies" sound nice for init, they're just a kludge. > > One example would be ntpd. Currently the thought is "ntpd has to go > after networking starts", and that's what would be expressed as a > dependency. > > But that sucks for a lot of reasons, especially in a scenario like the > one created by NetworkManager. What would be better is to make things > like ntpd start up, and use dbus to a) discover if there are any > networks available that are suitable for its purpose, and b) wait for > one to become available. So in this case basically NM could discover an > ntp server from the dhcp response, and then advertise it via dbus to > ntpd, which would add it in the pool as appropriate (depending on some > sort of policy or configuration). Well, it's still technically a dependency. In the situation you describe, there's really no reason for ntpd to start at all until NM declares there's some network connection available on which to actually sync to a server. > a) something which really must be run relatively early and in some > particular order (no point in doing a tsort for them, the ordering is > generally pretty obvious). We don't really care about these for this > discussion. Yeah, this is rc.sysinit at the moment - parallelization & dependencies here aren't really useful, as it follows pretty much in order: - load hardware modules - initialize storage - check & mount filesystems - misc boottime cleanups (/var, etc.) > In our current scenario, "some event" is something done by a different > initscript. In the dependency scenario, it's waiting on some side > affect of a script, and that satisfies the dependency. In most cases I > think it'd be better to have the other program notify things that the > real event we care about has happened, and the programs we're starting > respond accordingly. The initscript itself should be long gone (at > least conceptually) by the time that matters. The fun part will be rewriting the various apps/servers to sanely respond to runtime reconfigration like this. Bill -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
