lkml.org 
[lkml]   [2002]   [Nov]   [27]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 27 Nov 2002 10:51:54 -0800 (PST)
FromLinus Torvalds <>
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 12:31    [from the cache]
©2003-2008