From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Beginnings of conpat 32 code cleanups
Date: Mon, 25 Nov 2002 20:00:30 +0000 (UTC) [thread overview]
Message-ID: <artvgu$bgr$1@penguin.transmeta.com> (raw)
In-Reply-To: 20021123051628.GA3658@krispykreme
In article <20021123051628.GA3658@krispykreme>,
Anton Blanchard <anton@samba.org> wrote:
>
>_t32 == 32 bit version, its not the size. eg
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
next prev parent reply other threads:[~2002-11-25 19:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-22 5:23 [PATCH] Beginnings of conpat 32 code cleanups Stephen Rothwell
2002-11-22 19:47 ` Linus Torvalds
2002-11-22 19:54 ` Larry McVoy
2002-11-22 20:13 ` Cort Dougan
2002-11-22 20:38 ` H. Peter Anvin
2002-11-23 0:28 ` Stephen Rothwell
2002-11-25 19:48 ` Linus Torvalds
2002-11-23 5:16 ` Anton Blanchard
2002-11-25 20:00 ` Linus Torvalds [this message]
2002-11-26 13:53 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='artvgu$bgr$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.