On Wed, 20 Sep 2000 11:42:24 +0200,
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> To handle newer controllers which mimic older controllers, the newer
>> controllers would be listed in LINK_FIRST. At the moment we do not
>> have any plans to allow user ordering of controllers via .config, only
>> via editting the Makefile. The plan is to clean up the Makefiles
>> first, introducing new facilities comes later (if ever).
>
>Interesting. Do you mean that you don't want any user reordering via
>.config at all, or merely that you yourself have more
>important stuff to do. I can code up something myself if I
>feel the need. Complete control of order is ideal, it solves
>every problem an expert user might have. Ability to
>put one particular controller first solves the boot issues
>just fine though.
Current plans are to replace the current Makefile kludges with clean
code that does the same thing, gets it right where current Makefiles
are broken, is easier to maintain and (hopefully) is faster. The
kbuild mantra is "Correctness, Maintainability, Speed", in that order.
Part of the correctness and maintainability problem is the lack of
documentation on required link orders in the existing Makefiles.
People are scared to change the order of object entries because that
defines link order and we do not know if existing orders are required
or they are just coincidence.
Once the orders are fully defined as LINK_FIRST, LINK_LAST and the
rest, then we can think about allowing make xxx_config to change the
orders. However that would be after the Makefile rewrite had been
accepted. It would probably require the use of CML, I don't think the
current make xxx_config language can cope with this sort of input.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
