> doesn't change suddenly on the machine, there's no point at all in doing
> something like this and exporting it through proc, when the information is
> perfectly available in other ways
What other ways ? Dave M reasonably argued it wasn't part of the
architecture's ABI, so did not have a place in the headers.
> or could even be a user program config file option.
Eww.
> Quite frankly, just compile oprofile for the architecture and be done with
> it. Or add a command line option. Don't add stupid bloat to the kernel
> because somebody is silly enough to care about a 32-bit oprofile working
> with a 64-bit kernel.
It's not silly, it's a necessity on architectures like pa-risc, sparc64,
ppc64, etc. where pointers are 32 bit in userspace. OProfile simply
cannot work at all on such systems without being able to figure out the
units of the oprofile kernel buffer.
We could force the oprofile kernel buffer to always be u64s but that
just eats unnecessary space and time on x86.
So, what solution do you suggest instead ?
regards
john
-- "CUT IT OUT FACEHEAD" - jeffk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/