* Test the kernel code
@ 2019-10-05 3:07 CRISTIAN ANDRES VARGAS GONZALEZ
2019-10-05 3:52 ` Adam Zerella
2019-10-05 4:18 ` Valdis Klētnieks
0 siblings, 2 replies; 3+ messages in thread
From: CRISTIAN ANDRES VARGAS GONZALEZ @ 2019-10-05 3:07 UTC (permalink / raw)
To: kernelnewbies
[-- Attachment #1.1: Type: text/plain, Size: 254 bytes --]
Hello
I am starting to develop the kernel and I have been compiling the kernel,
now it has been compiling for some time now. When a patch is added, should
everything be compiled again? Or is there a different way to test the code
that has been written?
[-- Attachment #1.2: Type: text/html, Size: 447 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Test the kernel code
2019-10-05 3:07 Test the kernel code CRISTIAN ANDRES VARGAS GONZALEZ
@ 2019-10-05 3:52 ` Adam Zerella
2019-10-05 4:18 ` Valdis Klētnieks
1 sibling, 0 replies; 3+ messages in thread
From: Adam Zerella @ 2019-10-05 3:52 UTC (permalink / raw)
To: CRISTIAN ANDRES VARGAS GONZALEZ; +Cc: kernelnewbies
On Fri, Oct 04, 2019 at 10:07:21PM -0500, CRISTIAN ANDRES VARGAS GONZALEZ wrote:
> Hello
>
> I am starting to develop the kernel and I have been compiling the kernel,
> now it has been compiling for some time now. When a patch is added, should
> everything be compiled again? Or is there a different way to test the code
> that has been written?
From what I understand you'll only have to build the _entire_ kernel
once and subsequent builds should be faster. The build process should
rebuild modules that have a detected change in them.
You may be able to build the kernel a bit faster by running the process
in parallel. make has an argument of `-j` where you can specify the number
of CPU cores to utilise, for example `make -j4` would build with 4 CPUs
in parallel.
To build an individual kernel module you can specify something like `make
M=drivers/staging/android/`.
Checkout (no pun intended) https://kernelnewbies.org/KernelBuild for more info.
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Test the kernel code
2019-10-05 3:07 Test the kernel code CRISTIAN ANDRES VARGAS GONZALEZ
2019-10-05 3:52 ` Adam Zerella
@ 2019-10-05 4:18 ` Valdis Klētnieks
1 sibling, 0 replies; 3+ messages in thread
From: Valdis Klētnieks @ 2019-10-05 4:18 UTC (permalink / raw)
To: CRISTIAN ANDRES VARGAS GONZALEZ; +Cc: kernelnewbies
[-- Attachment #1.1: Type: text/plain, Size: 1711 bytes --]
On Fri, 04 Oct 2019 22:07:21 -0500, CRISTIAN ANDRES VARGAS GONZALEZ said:
> I am starting to develop the kernel and I have been compiling the kernel,
> now it has been compiling for some time now. When a patch is added, should
> everything be compiled again? Or is there a different way to test the code
> that has been written?
The kernel build is driven by 'make', which is a dependency-driven program that
only rebuilds things which have changed dependencies. How much actually gets
rebuilt depends on what exactly the patch changes.
It changes one .c file, it probably won't rebuild anything else. If the patch
touches a major .h file that's included in a lot of things, both direct *and*
indirectly from other .h files, you will probably be looking at a long rebuild
as every .c file that includes the affected .h file gets recompiled.
One crucial point to keep in mind - make is *not* smart enough to understand
that foo.c references 3 structures defined in bar.h - and that the patch
touches some other structure in bar.h that isn't used in foo.c. All it knows
is that foo.c #includes bar.h, and bar.h was modified (via checking the
timestamps), and thus a rebuild of foo.o is probably called for. If any of the
dependencies (usually the included .h files, but other dependencies can be
specified in the Makefile) has a newer last-modified timestamp than foo.c,
foo.c is getting rebuilt.
And then there's some changes that will end up forcing a rebuild of pretty much
everything in sight (for instance, anything that touches the top-level
Makefile, or certain other similar crucial files).
If you're not familiar with 'make', it's probably time you learned... :)
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-10-05 4:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-05 3:07 Test the kernel code CRISTIAN ANDRES VARGAS GONZALEZ
2019-10-05 3:52 ` Adam Zerella
2019-10-05 4:18 ` Valdis Klētnieks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).