> Much noise is made about the ordering problem, but as a practical
> matter, I've never seen any really complicated dependency graphs
> in system startups.  In most cases, one could probably just divide
> the startup into a small number of phases and leave it at that.

I think this is accurate.

I certainly know that i never, ever, _ever_ want an automated program:
	(1) possibly re-arranging the order that things are run at
	    boot time, after i have set the order,
	(2) need to be able to add things to the boot sequence from
	    single-user mode,
	(3) would prefer not to add more stuff to /.

basically, what this means is that i think schemes which use
dependency graphs to figure out when things need to be run are
overblown, and could be _dangerous_.


> If one used that approach, how many phases would be needed?
> How many of them might actually need actions added?

Perhaps: "before root is fsck'd," but i can't think of what would go
there.

> 	Before root is remounted read/write
> 	Before /usr (and others) are mounted
> 	Before switch to secure mode (load drivers?)

(of course, in current scheme, switch to 'secure mode' happens later,
but that should probably change, so that new network services that are
exported, etc., are always run when secure...)

> 	Before network is started up
> 	After network is started up
> 	After network daemons are up
> 	... (others?)

I can't think of any others...

but given those...  why not call them:

after 100: root is read-write
after 200: /usr and others are mounted
after 300: the system will be secure
after 400: network has been started
after 500: network daemons are going

or you could spread it out even more.


It's worth noting that i definitely think that once numbers are picked
for system service scripts, they shouldn't be changed by the system
developers.



chris