[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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
