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/
