Re: test10-pre7

[Peter Samuelson <peter@cadcamlab.org>]

[hpa]
> I would tend to agree with Linus on that.  If that's truly what
> you're doing, it would be rather nonobvious.

Well, ok, opinion vs. opinion.  The thing is, userspace code almost
*never* needs to care about link order -- and, not counting boot loader
magic, kernel code didn't care about it either until 2.3.16 or so
(debut of __initcall).  The reason link order suddenly became an issue
is that people started cutting out explicit lists of init code like
net/Space.c and relying on ld.  All in all that was a Good Thing -- it
made code more modular, etc.

My point here is that in most of the world, people are not accustomed
to caring about link order.  So I don't see why it's seen as such a
horrible thing to now say "ok link order is once again something you
ideally should not care about, *but* if there's a really good reason
otherwise, add your entry to LINK_FIRST."  Because the link-order-
*does*-matter paradigm is less than a year old, here.

> But the question, perhaps, is when does ordering matter.  I'm a
> little concerned about things highly dependent on link ordering.

Agreed.  And that is another point: we (Keith, Michael and I wrote all
this expecting link order to usually *not* matter -- LINK_FIRST was
just to cover corner cases.  Then we get Linus back saying the whole
drivers/scsi/ must be ordered *just so* (presumably so people don't
have to use boot flags for their multiple scsi host adapters) which is
either an unproven claim or, since it's Linus, a fiat.  (Which is OK,
don't get me wrong, better him than me making these decisions!)

And as for "rather nonobvious" -- it's not as if our stuff isn't
documented, at least.  Keith's patch includes several paragraphs added
to Documentation/kbuild/makefiles.txt, a file every kernel developer
should read anyway so that they know how to write correct makefiles.

Oh well.  Life goes on.  We can do fine without LINK_FIRST, but
possibly at the cost of increased cruft in the rest of the makefile
system.  (That depends on taste, I suppose.)

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/