On Tue, 26 Nov 2002, David S. Miller wrote:
>
> Linus what is you big beef with the names used before, the "__kernel"
> part of the name? We can't just use "u32" for ino_t althroughout the
> compat32 code or whatever your idea seems to be.
I have two _big_ beefs with the
__kernel_xxx_t32
naming:
- the xxx_t naming is already ugly, but at least it's standard ("_t
stands for typedef"). No such case is true for _t32.
- the __kernel_ naming is already ugly, but at least it has a _reason_
for it, namely that we have to have __ to avoid polluting user-space
headers with the _one_ thing that the kernel exports, namely
architecture types. Again, this is _not_ true for the compat32 stuff,
since it's an ABI, not an API issue, and the types aren't exposed to
user space headers.
In short, it's f*cking ugly, for no good reason. That in itself is _way_
enough reason to say "No FRIGGING WAY!".
The original patch was worse by an order of magnitude for _another_
reason, which has nothing to do with naming:
Note that I'm not against having architecture-specific "compat32 types".
HOWEVER, if they are architecture-specific, then they had better not be in
a generic file. So it's just _fundamentally_ wrong to have a <linux/xxx.h>
file that then has "architecture-specific" stuff in it. That's just CRAP.
So the naming is just ugly (but ugly enough that I don't want to see it).
The real crap is having a architecture-independent file that defines
non-generic types.
I suspect that the correct way to do things is:
- have an <asm/compat32.h> for the types. The types _are_ different for
different architectures, even if 90% of them look really really
similar. It's just not worth it trying to share code that is not
fundamentally the same - and in this case it isn't.
This fixes the fundamental objection I had to <linux/compat32.h>
- use sane naming. Something like "compat32_nlink_t" is sane. Something
like "__kernel_nlink_t32" is not.
You might as well also discuss just dropping the "32" from "compat32"
while you're at it. As far as I can tell the code and the fundamental
issue has nothing to do with 32-bitness per se. It has everything to do
with compatibility with an older ABI. The 32-bitness is a implementation
detail, there's nothing that fundamentally says the same compat code might
not work with a 64(user)->128(kernel) bit (or a 16->32 bit) compatibility
layer.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 30 2002 - 22:00:17 EST