On Wed, 16 Sep 2009, Geert Uytterhoeven wrote:
On Tue, Sep 15, 2009 at 12:16, Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx> wrote:
Warning: it may be rubbish, it may just be a hack which appeared to
work for me the last time I tried, on a particular address range of a
particular set of configurations of a particular set of architectures
(x86_32, x86_64, powerpc64). I've never thought it through enough to
consider submitting, but it _might_ contain something useful for you
to factor into your own efforts.
Sorry for chucking it over the wall to you in this way, but I guess
that's better than just sitting quietly on it for a few more years.
Certainly-Not-Signed-off-by: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>
I think that gives a good idea of the status of this patch:
I'm not making any policy decisions here or submitting to any tree.
--- 2.6.31/drivers/char/mem.c 2009-09-09 23:13:59.000000000 +0100
+++ 2.6.31d/drivers/char/mem.c 2009-09-10 09:38:30.000000000 +0100
-#ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED
- /* we don't have page 0 mapped on sparc and m68k.. */
Is this `feature' removed?
The feature that some arches don't have page zero mapped?
No, I could hardly change that from drivers/char/mem.c,
and wouldn't wish to.
The feature that reading from one unmapped page gave zeroes
and writing to it threw away what you wrote? Yes, in making
that patch, I was thinking that if we cope with unmapped areas
elsewhere by returning -ENXIO, it made little sense to have
special code to do something different for page zero.
But of course there might be userspace compatibility reasons
why that couldn't change e.g. a body of /dev/kmem users who
would be surprised by an error right at the "start" (though
in kmem's case, they've already had to seek to get anywhere).
Take the patch as saying "hmm, I wonder if we could do it this way".
Hugh
