Messages in this thread |  | | From | Peter Samuelson <> | Date | Wed, 1 Nov 2000 00:31:19 -0600 (CST) | Subject | Re: test10-pre7 |
| |
[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/
|  |