Re: Where did vm_operations_struct->unmap in 2.4.0 go?

[Keith Owens]

On Fri, 12 Jan 2001 13:01:12 +0100, 
Daniel Phillips <[e-mail]> wrote:
>Keith Owens wrote:
>> I want to completely remove this multi layered method for setting
>> initialisation order and go back to basics.  I want the programmer to
>> say "initialise E and F after G, H and I".  The kernel build system
>> works out the directed graph of initialisation order then controls the
>> execution of startup code to satisfy this graph.
>
>I don't doubt you will come up with a workable solution at build time. 
>However, working out a valid graph at execution time is trivial and
>efficient, given a list of precedence relations of the kind you're
>suggesting.  In fact you don't even have to work out the graph before
>starting the initialization, it's also trivial to keep a count of
>unsatisfied initialization conditions at the beginning of each
>initialization sequence and block until the count goes to zero.  (In
>essence, evaluate a priority sort on the fly.)

It is safer to evaluate the graph at link time in case somebody
mistakenly codes a dependency loop, that is an abort case.  Finding
that you have a loop at load time and aborting the kernel is a little
too drastic for my tastes.

In any case it is academic.  Linus insists on link order being
explicitly and completely specified by the programmer and he likes the
link order being implied by Makefile order.  So there is no point in
working on a better system.