->What you can do is instead of trying to replace the kernel with a new
->kernel, you can add a fixed function to the kernel while retaining the
->old function. For code-changes I can imagine you could do something
->like the following:
Perhaps, I was not clear, but I never said that I'm going to replace
whole kernel. My idea was just to patch selected parts of kernel
(functions, that is) with new ones.
->You have one running kernel and a set of patches to that kernel. Each
->patch is defined as a code-segment with one entry-point and a set of
->entry-points in the kernel that should be replaced by the entry-point
->in the patch. You pack each patch into a separate kernel-module, and
->when loaded, they overwrite the first instruction of each of the
->defined entry-points in the kernel with a jump-instruction to the
->entry-point in the module. On unload, you write back the saved
->contents of the first instructions of the entry-points in the
->kernel.
->
->You won't have any trouble with pointers to functions and in many
->(most?) cases, patching the kernel can be done with _one_ atomic write
->operation which makes it unnecessary to "take down" the kernel at all.
It is __EXACTLY__ what my patch already does. If you wnat you can d/l it
and take a look.
The problem is that the function I patch may want to call other
parts of the kernel. If given function or data structure is "exported"
by kernel, then insmod will do all the dirty job and I can use it.
It the given data structure is not exported. Then I can specify its
adddres, and use ptrs.
While it is doable, my idea was to be able to "modularize" any function
by just taking it out of kernel sources putting into module and have it
replace identical function.
Then I can change that new function at my will.
It does work perfectly for ip_glue (off by one bug), as it does not
call any unexported data structires, the problem of fixing sigio bug
is that that function refers to wake_up_process and init_task_union.
Neither of those is exported by kernel, so insmod won't do the dirty
job for me. So I the only way to access them is via ptrs. But it
imples i have to modify the send_sigio_new(), what kind of defeats
point of this patch which main idea was ease-of-design.
To repat, what I'm hoping is to have some kind of "interface" which will
let me separate the "patch" from all the dirty details of insmod. That is
that I can just take buggy function of kernel, fix it put itno module. --
it works exactly as I would wish, and as I said above, for ip_glue, but
not for sigio :(
If you are interested you can look it up at
ftp://ftp.cfar.umd.edu/pub/adam/linux/LKPK-BETA-0.5.tgz
Keep in mind that while the obo (off-by-one) the proof of concept
and proves that it works, if you are interested in development
you should look at sigio patch wish is much more neat to look at :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html