[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071002075549.GH19691@waste.org>
Date: Tue, 2 Oct 2007 02:55:49 -0500
From: Matt Mackall <mpm@...enic.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
"Huang, Ying" <ying.huang@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Lameter <clameter@....com>, apw@...dowen.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: x86 patches was Re: -mm merge plans for 2.6.24
On Tue, Oct 02, 2007 at 12:18:09AM -0700, Andrew Morton wrote:
> > > If so, that might be OK - the app just needs a reliable way of working out
> > > whether it's on a 32- or 64-bit kernel?
> >
> > That would be ugly and a little error prone (would this case really be
> > tested in user space normally?) but might work.
>
> I guess it wouldn't be too hard for a 64-bit kernel to fake up 32-bit data
> for 32-bit userspace. For each architecture :( But let's see what Matt
> thinks.
Grumble. The options are:
a) export it in the kernel's native size and have userspace figure it
out
b) add a header
c) lie to 32-bit apps on 64-bit kernels
d) always export 32 bits
e) always export 64 bits
I started with (a), switched to (b), and then Alan and Dave convinced
me to switch back to (a). I don't think (c) is desireable, especially
as it means having two code paths. (d) would work until memory got
large enough that PFNs didn't fit in 32 bits. (e) would be ok all
around, except for the extra overhead. Ho hum.
--
Mathematics is the supreme nostalgia of our time.
-
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