lkml.org 
[lkml]   [2002]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.081 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site