[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46A0F4AC.50809@zytor.com>
Date: Fri, 20 Jul 2007 10:45:16 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andreas Schwab <schwab@...e.de>
CC: "Luck, Tony" <tony.luck@...el.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Andi Kleen <ak@...ell.com>,
Arthur Jones <arthur.jones@...gic.com>,
Vasily Tarasov <vtaras@...nvz.org>,
linux-kernel@...r.kernel.org, Jan Kara <jack@....cz>,
linux-arch@...r.kernel.org
Subject: Re: build fix for x86_64...
Andreas Schwab wrote:
> "H. Peter Anvin" <hpa@...or.com> writes:
>
>> No, that would be bad. If compat_u64 is used to carry 32-bit ABIs
>> forward into 64-bit space without needing compatibility hacks, then this
>> would actually introduce ABI incompatibilities depending on CONFIG_COMPAT!
>
> But without CONFIG_COMPAT there is no 32-bit ABI, thus no need for
> compat_u64 in the first place.
>
You're missing the point.
Someone introduces an interface, which uses a structure:
struct foo {
u32 bar;
u64 baz;
u32 quux;
};
Now, we want to port that to 64 bits. We can either introduce a
thunking function to mangle the argument, or we can redefine the structure:
struct foo {
u32 bar;
compat_u64 baz;
u32 quux;
};
... which is still ABI compatible on 32 bits, but doesn't require thunking.
Obviously, this is not a panacea; if the original "struct foo" has also
been introduced on 64 bits before the bug is caught, then you're screwed.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists