Oh, I realize that. What I do not see is the point of the typedefs AT
ALL. They must go. They are crap. They have no reason for their
existence.
>asm-ia64/ia32.h: typedef unsigned short __kernel_ipc_pid_t32;
>asm-mips64/posix_types.h: typedef int __kernel_ipc_pid_t32;
>asm-parisc/posix_types.h: typedef unsigned short __kernel_ipc_pid_t32;
>asm-ppc64/ppc32.h: typedef unsigned short __kernel_ipc_pid_t32;
>asm-sparc64/posix_types.h: typedef unsigned short __kernel_ipc_pid_t32;
>asm-x86_64/ia32.h: typedef unsigned short __kernel_ipc_pid_t32;
>
>Or do you mean we should use typedef u16 __kernel_ipc_pid_t32? Yeah,
>I can understand that.
That helps, by removing half of the reason why they are crap - the using
of types that are not architecture-safe in a generic ABI file. But the
other half of the reason is still there:
It doesn't remove the rest of the reason: that "__kernel_" prefix is
meaningless (since the type shouldn't be visible in a non-kernel
namespace ANYWAY, and that is the only reason for the prefix in the
first place).
Basically, you have two cases:
- you have types that are _truly_ generic 32-bit compatibility stuff,
and are the same on all architectures that use this compatibility
layer.
But if they are truly generic, they shouldn't need a new typedef AT
ALL. You should just realize that "loff_t" is always a "s64", and
then just use s64 in the compatibility functions/structures. No need
to make up some new typedef.
- You have types (like the above) where the compatibility layer
actually has _different_ types for different architectures. In which
case they should be in an architecture-specific file, not in some
generic file. And the name should not be "__kernel_xxxx_t32", but
"compat32_xxxx_t" or something.
In _neither_ case is it valid to have a generic architecture-independent
file that makes up new types. See? And THAT is why I thin kthe patch is
crud.
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/