Luck, Tony wrote:
> At the moment our problem is that there is some code that has
> been added to handle the compatability problem caused by u64
> objects having different alignment when running on 32-bit and
> 64-bit systems. This only affects ia64 and x86-64 because all
> the other 32/64 bit cap
At the moment our problem is that there is some code that has
been added to handle the compatability problem caused by u64
objects having different alignment when running on 32-bit and
64-bit systems. This only affects ia64 and x86-64 because all
the other 32/64 bit capable systems wisely avoided
Andi Kleen wrote:
>> Obviously, this is not a panacea; if the original "struct foo" has also
>> been introduced on 64 bits before the bug is caught,
>
> That's usually the case. There is already an established 64bit ABI
>
This is true.
Kind of makes me wonder if the right thing is to introduce
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> struct foo {
> u32 bar;
> compat_u64 baz;
> u32 quux;
> };
compat_u64 is only for use in CONFIG_COMPAT code.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germ
> Obviously, this is not a panacea; if the original "struct foo" has also
> been introduced on 64 bits before the bug is caught,
That's usually the case. There is already an established 64bit ABI
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Andreas Schwab wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> 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!
>
"H. Peter Anvin" <[EMAIL PROTECTED]> 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
Andi Kleen wrote:
>
> That doesn't help for any old interfaces, like the one here. For those
> still ifdefs are needed. Interfaces that use compat_u64 just use
> a normal #ifdef CONFIG_COMPAT.
>
> Besides I have my doubts compat_u64 will be the solution
> to these worries. We have hundreds of peo
On Friday 20 July 2007 19:03, H. Peter Anvin wrote:
> Luck, Tony wrote:
> > Which is better. But if we unconditionally set this CONFIG variable,
> > then the code in fs/quota.c will have to read:
> >
> > #if defined(CONFIG_COMPAT) && defined(CONFIG_COMPAT_FOR_U64_ALIGNMENT)
> >
> > We can keep it
Luck, Tony wrote:
>
> Which is better. But if we unconditionally set this CONFIG variable, then the
> code in fs/quota.c will have to read:
>
> #if defined(CONFIG_COMPAT) && defined(CONFIG_COMPAT_FOR_U64_ALIGNMENT)
>
> We can keep it simpler if the Kconfig file does the conditional for us:
>
>
On Fri, Jul 20, 2007 at 09:20:15AM -0700, Luck, Tony wrote:
> Which is better. But if we unconditionally set this CONFIG variable, then the
> code in fs/quota.c will have to read:
>
> #if defined(CONFIG_COMPAT) && defined(CONFIG_COMPAT_FOR_U64_ALIGNMENT)
>
> We can keep it simpler if the Kconfig
> Half dozens?
I was imagining having to have "help" messages ... which of course we don't.
> config COMPAT_FOR_U64_ALIGNMENT
> bool
> default y
Plausible.
Randy suggested:
> def_bool y
Which is better. But if we unconditionally set this CONFIG variable, then the
code in fs/
On Fri, 20 Jul 2007 10:32:47 +0200 Andi Kleen wrote:
> On Friday 20 July 2007 01:54:51 Luck, Tony wrote:
>
> > > Tony, perhaps it would make sense to define some common CONFIG
> > > for COMPAT_FOR_U64_ALIGNMENT longer term to make the #ifs for this
> > > case a little less ugly.
> >
> > Certain
On Friday 20 July 2007 01:54:51 Luck, Tony wrote:
> > Tony, perhaps it would make sense to define some common CONFIG
> > for COMPAT_FOR_U64_ALIGNMENT longer term to make the #ifs for this
> > case a little less ugly.
>
> Certainly if there is ever a third architecture that needs this the
> #if m
> Looks good.
Looks good to me too (I'm to blame for the version posted by Doug
that only fixed ia64 ... I didn't take the time to check whether
there was a CONFIG_COMPAT option for x86_64 ... oops).
> Tony, perhaps it would make sense to define some common CONFIG
> for COMPAT_FOR_U64_ALIGNMENT l
On Friday 20 July 2007 00:24:11 Arthur Jones wrote:
> hi vasily,
>
> commit b716395e2b8e450e294537de0c91476ded2f0395
> breaks the build for x86_64 (and ia64 too, i guess) if
> CONFIG_COMPAT is not turned on. here is a patch, which
> i think is more complete than the previous one posted
> to LKML
16 matches
Mail list logo
