Keith Owens writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
>> The infamous LINK_FIRST infrastructure was sort of half-way done.
>>
>> It would be best to cause drivers with an unspecified link order
>> to move around a bit, so that errors may be discovered more quickly.
>
> The "other" list in LINK_FIRST is sorted by name. It could be changed
> to a random sort, probably based on a hash of size and mtime. It would
> be relatively expensive so would have to be restricted to a "exercise
> the kernel" CONFIG option.
Yes, throwing out the low bits of mtime so that everybody gets the
same link order for a week. (must be able to reproduce failures)
>> LINK_FIRST is pretty coarse. One would want a topological sort,
>> or at least LINK_0 through LINK_9 _without_ anything else.
>
> There is no need for multiple LINK_n entries, the objects partition
> neatly into three groups. LINK_FIRST objects, in the order they are
> defined. The rest of the objects (object list - (LINK_FIRST +
> LINK_LAST), in an undefined order. LINK_LAST objects, in the order
> they are defined.
Ah, but then Linus has an argument to crush you. There is no
reason left to have anything but LINK_FIRST, and so the rest
is redundant and you can just kill the whole idea.
Going with multiple LINK_n entries and nothing else makes it
possible to make order dynamic within any LINK_n group. This
forces eventual discovery of any problems.
> If you can come up with a concrete link order example that
> cannot be handled by a three partition model then I will
> listen. Otherwise it is just over engineering.
The three-partition model is over-engineering, because it adds
extra complexity without getting rid of the fixed-order group.
Instead you get two fixed-order groups and one dynamic-order one.
If we are to leave the current model of a single fixed-order
group, then we ought to switch to something else uniform.
The three groups you desribe just isn't very regular.
-
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/
