login
Search
On Fri, 19 Jan 2007, Nadia Derbey wrote: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. 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 -