Boot poster challenge

Michael Favia michael at insitesinc.com
Mon Nov 15 18:09:11 UTC 2004


Arjan van de Ven wrote:

>On Mon, 2004-11-15 at 12:56 +0100, Ralf Ertzinger wrote:
>  
>
>>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 ...
>  
>
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.

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




More information about the fedora-devel-list mailing list