On Fri, 19 Jan 2007, Nadia Derbey wrote:
> Hugh Dickins wrote:
> >
> > Sigh, you're right, 2.6.19 messed that up completely.
> > No, you never had to subtract PAGE_OFFSET from that address
> > in the past, and you shouldn't have to do so now.
Whoops, I should never have said "never". Checking further back,
I found that in 2.4, and prior to 2.6.12, mmap_kmem was simply
#defined to mmap_mem, and so you would then have had to subtract
PAGE_OFFSET (well, on i386 at least) from the kernel virtual
address to get it to work.
Andi fixed that in 2.6.12. I agree with his fix: the same data should
appear at the same offset whether you use mmap or read, which was not
so before his patch (nor after Franck's). Though I do wonder whether
it was safe to change its behaviour at that stage: more evidence that
few have actually been using mmap of /dev/kmem.
> > I guess it's reassuring to know that not many are actually
> > using mmap of /dev/kmem, so you're the first to notice: thanks.
> >
> I find this feature very interesting from a testing perspective. Now, since I
> don't like the idea of being the only one that uses a feature (not maintained
> - may be even to be removed?) may be you could advice me on a more broadly
> used way to get the value of a non exported kernel variable from inside a test
> running in user mode? should I use /dev/mem instead? But in that case, I
> should do the virtual to physical conversion myself, right?
That's exactly the way I've used mmap of /dev/kmem in the past myself:
yes, a convenient way to collect stats or patch flags when investigating
something on a private kernel. There are probably more sophisticated
alternatives now (systemtap, [a-z]probes), but mmap of /dev/kmem is
pretty easy to understand, whatever its limitations.
You're right to question whether you'll be safer in the long term to
use /dev/mem instead, doing the virtual to physical conversion yourself:
I share your doubt. On the one hand, /dev/kmem is clearly underused,
with an interface which changes without anyone noticing; and Fedora
doesn't even supply the node (they'd like to get rid of /dev/mem also,
I believe - too wide an open door into the kernel - but a few tools
still use it). On the other hand, if for some reason we make the
mapping between physical and kernel virtual more complicated in
future, /dev/kmem should in theory save you from having to worry
about that (though in practice none of us has ever got around to
supporting mmap of the vmalloc area through /dev/kmem yet).
I think, if this thread provokes a call to remove support for mmap
of /dev/kmem, I'd find that hard to argue against, and you'd better
switch to /dev/mem. But personally I'd prefer it to remain.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
