Arjan van de Ven wrote:
On Mon, 2004-11-15 at 12:56 +0100, Ralf Ertzinger wrote:A dependency based init system that registers the necessary devices, services, and paths (all known as "entities" from here forward) for proper startup for a service seems to be an elegant solution that provides enough information to facilitate the decision making process for the init process. The idea of dependency based inits without specifying what each service is actually needs and provides is always going to yield no improvement because it doesnt attack the real granularity of the problem. (e.g. the example above really needs a directory provided by a NFS mount not the NFS service itself so checking for the availability of that path would test the real necessity of adding network infrastructure to the dep list). Sometime you require actual services (hald), certain devices (/dev/video0) or maybe just particular paths (/home/myUsername) regardless the point is the same.
WRT DHCP: why does FC wait in the foreground to get an IP? Is there a
magic switch I haven't found yet to make that a background process?
nfs mounted dirs ...
Required/requested entities are registered when the service begins its initialization and provided entities are registered upon its completion. In case a service is queued up without its proper dep entities it will wait until they are provided or the init process is complete upon which they will error out. Once they are located it will add the service responsible for providing the required entity to its registered list of entity deps so next time the boot is more streamlined. Because the registered entity dep list knows which services provide particular entities (because services register the entities they provide). It can easily recognize when a registered dep is no longer necessary and can remove it from the dep list for the next reboot. This dynamic relationship might increase the time for any single boot early on if poorly configured by default but will decrease the average time for the boot process with each restart. It also evolves when required entities change how they are provided.
I acknowledge that i am grossly unfamiliar with a large portion of the startup process but i ask that you attempt to find the benefits of such a system and try to mitigate the detrimental effects before you emphasize its shortcomings. I'm probably missing entity types and oversimplifying the tasks but it just makes sense that if we want these dynamic environments to be as efficient as possible we have to provide them with the information to make that decision in the first place. No "default" will work for everyone and i think if done properly the overhead of a dynamic system can be a net gain for all if it isnt "reconfigured" every time but instead cached until next boot which ensures proper function and the ability to undo any negative changes if necessary.
Best Wishes, -mf
