> > no strong opinion from me - but i think it should be obvious to the > developer when they are looking at a .c file that it's 32-bit only (or > 64-bit only). I.e. the default is that whatever .c file we look at is > unified - and in that sense relocs.c breaks that general expectation.
I for one would like to see when stuff is 32 bit only and when shared across 32 and 64 bit. And this type of info is useful when I do greps so hiding the information in a Makefiel is then no good. It helps your understanding when you get the most correct picture of where a certain symbol is used - a functionality I often need. And this is by no menas limited to a narrow x86 view but across the full kernel. So I, and this is no news for Ingo, would like to see what is solely for 32 bit to be marked as such. And we are heading with full speed to the situation for x86 where the number of foo_32.c, foo_64.c are minimal. But that said we will likely see a small decrease in speed now. As for the Makefiles - I looked at them last time and only issue that kept me away for unifying them was that I did not understand the linking order requirments and I did not see enough benefit at that time to invest the time to unify them. Each of the remaining Makefile should be unifyable in less than 10 steps each. It is just work that are waitng to be done. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/