Messages in this thread | | | Date | Wed, 27 Nov 2002 10:51:54 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [PATCH] Start of compat32.h (again) |
| |
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/
| |