On 07 Mar 2003 15:14:15 -0500, Albert Cahalan wrote:
>Mikael Pettersson writes:
>
>> I'm planning to simplify the kernel <--> user-space
>> interface in perfctr-2.6 (drop /proc/pid/perfctr and
>> go back to /dev/perfctr), and then I _think_ I can
>> do a version that doesn't require patching kernel
>> source. (It will do binary code patching at module
>> load-time instead. Horrible as that sounds, it's
>> easier to deal with for users.)
>
>That would make porting more difficult. I don't think
>these changes will help you gain acceptance.
I don't like patching kernel object code at all. But the #1
usability problem I'm facing is that to use the stuff, people
_must_ patch and rebuild their kernels, due to the callbacks
from switch_to and a few other places, and the task_struct
layout change. That scares away some people, and some try it
but get it wrong with confusing (and hard to debug) results.
(Besides, patching and recompiling the kernel doesn't always work.
There are examples of binary-only HW vendor modules that are
specific to certain versions of certain vendors' binary kernels.)
Naturally, the normal procedure of rebuilding the kernel from
patched sources would remain as the default. The object code
patching approach (which is what I'd use for a plug-and-play
binary .rpm for example) would basically use System.map and a
glue module to do the patching (installing callbacks), and then
the stock driver module would be inserted as usual.
With Linus ignoring the patch, the driver needing callbacks from
process scheduling/fork/exit/execve points, and users having
problems with kernel recompiles, what do you expect me to do?
/Mikael
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:40 EST