Robert Elz writes:
> In any case, any tools that are going to be useful to kernel hackers
> will be maintained in a state that they work, the kernel people will make
> sure of that - and no-one is suggesting that should not be done.  It is
> just that attempting to invent a new (object filename independant) way of
> getting offsets into /dev/kmem just has to be an unproductive way to
> spend time.   If there is to be a change at all, let it be a significant
> step forward, not just another wart.

I think the only solution here is to come up with a library for doing
the kernel memory grovelling that works just as well in a
procfs/kernfs/sysctl universe as in a dead kernel universe. Someone
clever can perhaps come up with a way to do this. It is okay if it
means having the same .c file used by the kernel and by some library,
but it is not a good thing if it means having the kernel and userland
duplicate code somehow.

Perry