Hi,
I know when you work on some kernel module, you can change code and load
module again and test it, but what if you change some built in kernel
.c file, why
would I need to recompile whole kernel just to see what happens if I change one
.c file ??
Why can I just compile one changed .c file and copy it where compiled version of
that file reside inside kernel tree? Or maybe there is some image info embedded
inside compiled files, so that file must belong to specific image from
which it is
installed ?
Thanks,
Dragoslav Zaric
On Sun, 2009-03-22 at 11:43 +0100, Dragoslav Zaric wrote:
> Hi,
>
> I know when you work on some kernel module, you can change code and load
> module again and test it, but what if you change some built in kernel
> .c file, why
> would I need to recompile whole kernel just to see what happens if I change one
> .c file ??
>
> Why can I just compile one changed .c file and copy it where compiled version of
> that file reside inside kernel tree? Or maybe there is some image info embedded
> inside compiled files, so that file must belong to specific image from
> which it is
> installed ?
>
hmm, everything is possible. If you want this feature then place an
order ;-)
Just curious do you want to reboot your system or you also want to see
the effect of that file in running kernel.
--
JSR
On Sun, Mar 22, 2009 at 11:43:28AM +0100, Dragoslav Zaric wrote:
> Hi,
>
> I know when you work on some kernel module, you can change code and load
> module again and test it, but what if you change some built in kernel
> .c file, why
> would I need to recompile whole kernel just to see what happens if I change one
> .c file ??
>
> Why can I just compile one changed .c file and copy it where compiled version of
> that file reside inside kernel tree? Or maybe there is some image info embedded
> inside compiled files, so that file must belong to specific image from
> which it is
> installed ?
Well, in some cases you can do that. For very minor changes (constants,
disabling 'if' statements, breaking out of loops, or returning from
functions), tampering the memory with an hex editor is often more
convenient than rebooting. /proc/ksyms is your friend here. It also
sometimes help you see the effect of your changes. But you must always
be ready to reboot anyway because mistakes are quite common and generally
don't leave you with a second chance.
Willy
On Sun, 22 Mar 2009, Dragoslav Zaric wrote:
> Hi,
>
> I know when you work on some kernel module, you can change code and load
> module again and test it, but what if you change some built in kernel
> .c file, why
> would I need to recompile whole kernel just to see what happens if I change one
> .c file ??
>
Depends on the nature of the change. Some changes will ripple through the
whole kernel.
If, for example, you made a change to kmalloc() so that it takes an extra
argument, then obviously all call sites would need changing and since
kmalloc is used almose everywhere, then almost all files would need to be
recompiled.
But if your change is entirely contained to a single file, then 'make'
will already ensure that only that file is rebuilt when you run 'make'
(you'll still have to re-link the kernel or module though and a reboot
will still be needed).
> Why can I just compile one changed .c file and copy it where compiled version of
> that file reside inside kernel tree?
'make' should already handle that for you. In what way does it not?
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
On Sun, Mar 22, 2009 at 6:43 AM, Dragoslav Zaric
<[email protected]> wrote:
> Hi,
>
> I know when you work on some kernel module, you can change code and load
> module again and test it, but what if you change some built in kernel
> .c file, why
> would I need to recompile whole kernel just to see what happens if I change one
> .c file ??
>
> Why can I just compile one changed .c file and copy it where compiled version of
> that file reside inside kernel tree? Or maybe there is some image info embedded
> inside compiled files, so that file must belong to specific image from
> which it is
> installed ?
ksplice can do this in some limited cases: http://www.ksplice.com/example-update
Obviously, changes which affect the structure of kernel datastructures
are more difficult to accomplish...
On Sun, Mar 22, 2009 at 9:29 PM, Jesper Juhl <[email protected]> wrote:
> On Sun, 22 Mar 2009, Dragoslav Zaric wrote:
>
>> Hi,
>>
>> I know when you work on some kernel module, you can change code and load
>> module again and test it, but what if you change some built in kernel
>> .c file, why
>> would I need to recompile whole kernel just to see what happens if I change one
>> .c file ??
>>
> Depends on the nature of the change. Some changes will ripple through the
> whole kernel.
> If, for example, you made a change to kmalloc() so that it takes an extra
> argument, then obviously all call sites would need changing and since
> kmalloc is used almose everywhere, then almost all files would need to be
> recompiled.
> But if your change is entirely contained to a single file, then 'make'
> will already ensure that only that file is rebuilt when you run 'make'
> (you'll still have to re-link the kernel or module though and a reboot
> will still be needed).
>
>> Why can I just compile one changed .c file and copy it where compiled version of
>> that file reside inside kernel tree?
>
> 'make' should already handle that for you. In what way does it not?
>
> --
> Jesper Juhl <[email protected]> ? ? ? ? ? ? http://www.chaosbits.net/
> Plain text mails only, please ? ? ?http://www.expita.com/nomime.html
> Don't top-post ?http://www.catb.org/~esr/jargon/html/T/top-post.html
>
>
Well it looks like I didn't read about "make" command a lot :)
This is what I found :
--------------------------------------------------------------------------------------------------------------------------------------------------------
| Once a suitable Makefile exists, each time you change some source
files, this simple shell command:
|
| make
|
| suffices to perform all necessary recompilations. The make program
uses the makefile data base and
| the last-modification times of the files to decide which of the
files need to be updated. For each of those
| files, it issues the commands recorded in the data base.
--------------------------------------------------------------------------------------------------------------------------------------------------------
So this is what I would (will) do if I want to debug, change or add
some kernel feature and don't want to wait a
lot of time every time :) :
Build version of kernel that has minimum modules (and other stuff) to
run your machine (unchecked things in
.config file will decrease time) and when work on some feature, then
add just stuff you wanna debug or
change and then run
make
thanks,
dragoslav