Hey Guys,
I've been looking to hacking at the kernel for a long time now.
I've managed to have a good setup, build the latest stable kernel and
boot from it. I've read some of the docs, Coding Styles etc and
watched GregKH's talks on youtube. I'm also reading Robert Love's
Linux Kernel Development.
Id like now to get my hands dirty but I can't seem to find something
simple to do. I posted to kernel janitors and kernel mentors, but no
dice. The bugs list looks thoroughly contrived.
I've made small contributions to other OSS projects before but now I'm
at a loss for how to study the kernel code base, what to try to
break/change to study how the kernel works.
Is there some simple work a newbie like me can take up? Any maintainer
need some grunt work done? Or perhaps someone could suggest a pet
project I could try to understand things better? (Should I be learning
how to write device drivers?)
Things that are very interesting to me so far are the KVM and the Scheduler.
Regards,
Gideon
Hi Gideon,
On Sat, 04 January 2014 "Gideon D'souza" <[email protected]> wrote:
> I've been looking to hacking at the kernel for a long time now.
>
> I've managed to have a good setup, build the latest stable kernel and
> boot from it. I've read some of the docs, Coding Styles etc and
> watched GregKH's talks on youtube. I'm also reading Robert Love's
> Linux Kernel Development.
>
>
> Id like now to get my hands dirty but I can't seem to find something
> simple to do. I posted to kernel janitors and kernel mentors, but no
> dice. The bugs list looks thoroughly contrived.
>
> I've made small contributions to other OSS projects before but now I'm
> at a loss for how to study the kernel code base, what to try to
> break/change to study how the kernel works.
>
> Is there some simple work a newbie like me can take up? Any maintainer
> need some grunt work done? Or perhaps someone could suggest a pet
> project I could try to understand things better? (Should I be learning
> how to write device drivers?)
>
> Things that are very interesting to me so far are the KVM and the Scheduler.
Starting with writing some driver (or improving existing drivers) is one
option, though that wont get you doing work in relation with the scheduler
(maybe there is some minor driver-like work for KVM though, don't know).
A better start, and at least as useful is to read and review patches
flowing by that affect your areas of interest, test them and provide
feedback about possible bugs or improvements (proposing patches to fix
those if applicable or even just providing performance data [what
workloads benefit or suffer from given feature-patches and by how much]
for things like scheduler changes).
This way you will get to know the development process, maintainers
and the internals of the kernel in those areas - don't forget to subscribe
to the specific mailing lists!
Regards,
Bruno
> Regards,
> Gideon
On Sat, Jan 4, 2014 at 9:36 PM, Bruno Prémont <[email protected]> wrote:
>> Is there some simple work a newbie like me can take up? Any maintainer
>> need some grunt work done? Or perhaps someone could suggest a pet
>> project I could try to understand things better? (Should I be learning
>> how to write device drivers?)
>>
>> Things that are very interesting to me so far are the KVM and the Scheduler.
>
> Starting with writing some driver (or improving existing drivers) is one
> option, though that wont get you doing work in relation with the scheduler
> (maybe there is some minor driver-like work for KVM though, don't know).
>
> A better start, and at least as useful is to read and review patches
> flowing by that affect your areas of interest, test them and provide
> feedback about possible bugs or improvements (proposing patches to fix
> those if applicable or even just providing performance data [what
> workloads benefit or suffer from given feature-patches and by how much]
> for things like scheduler changes).
>
> This way you will get to know the development process, maintainers
> and the internals of the kernel in those areas - don't forget to subscribe
> to the specific mailing lists!
Yep, all very good advices. And while following the above, you will hopefully
notice things that need bug fixes, cleanups, or other work.
E.g. one thing I just noticed: while include/linux/compiler-gcc.h provides
shorthands (e.g. "__printf()") for various gcc __attribute__ macros, there
are still many places that don't use the shorthands, cfr. e.g.
"git grep 'attribute.*printf'".
As some of these are in architecture-specific header files, and need build
testing there, this is an opportunity to get some cross-compilers going (you
can download binaries from https://www.kernel.org/pub/tools/crosstool/) as
well.
Good luck, thanks, and welcome to the team! ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Thanks so much Geert and Bruno for your replies:
>>don't forget to subscribe to the specific mailing lists!
Didn't know about this, this link is the right one?
http://vger.kernel.org/vger-lists.html#cpufreq There isn't a list for
the scheduler though?
>A better start, and at least as useful is to read and review patches flowing
> by that affect your areas of interest, test them and
> provide feedback about possible bugs or improvements
This is a really good idea, so far though all the patches to me look a
little arcane, for things I barely understand. But I will keep
looking. If I do find something, lets say a patch to the scheduler or
some networking thing, how do you guys really test this out? How to
you debug a scheduler? :/ How do I really "See" the system run? Put
printk statements here are there?
>E.g. one thing I just noticed: while include/linux/compiler-gcc.h provides
>shorthands (e.g. "__printf()") for various gcc __attribute__ macros, there
>are still many places that don't use the shorthands, cfr. e.g.
>"git grep 'attribute.*printf'".
Are trivial patches like this really accepted?
Regards,
Gideon
On Sun, Jan 5, 2014 at 3:02 PM, Geert Uytterhoeven <[email protected]> wrote:
> On Sat, Jan 4, 2014 at 9:36 PM, Bruno Pr?mont <[email protected]> wrote:
>>> Is there some simple work a newbie like me can take up? Any maintainer
>>> need some grunt work done? Or perhaps someone could suggest a pet
>>> project I could try to understand things better? (Should I be learning
>>> how to write device drivers?)
>>>
>>> Things that are very interesting to me so far are the KVM and the Scheduler.
>>
>> Starting with writing some driver (or improving existing drivers) is one
>> option, though that wont get you doing work in relation with the scheduler
>> (maybe there is some minor driver-like work for KVM though, don't know).
>>
>> A better start, and at least as useful is to read and review patches
>> flowing by that affect your areas of interest, test them and provide
>> feedback about possible bugs or improvements (proposing patches to fix
>> those if applicable or even just providing performance data [what
>> workloads benefit or suffer from given feature-patches and by how much]
>> for things like scheduler changes).
>>
>> This way you will get to know the development process, maintainers
>> and the internals of the kernel in those areas - don't forget to subscribe
>> to the specific mailing lists!
>
> Yep, all very good advices. And while following the above, you will hopefully
> notice things that need bug fixes, cleanups, or other work.
>
> E.g. one thing I just noticed: while include/linux/compiler-gcc.h provides
> shorthands (e.g. "__printf()") for various gcc __attribute__ macros, there
> are still many places that don't use the shorthands, cfr. e.g.
> "git grep 'attribute.*printf'".
>
> As some of these are in architecture-specific header files, and need build
> testing there, this is an opportunity to get some cross-compilers going (you
> can download binaries from https://www.kernel.org/pub/tools/crosstool/) as
> well.
>
> Good luck, thanks, and welcome to the team! ;-)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
On Sun, 05 January 2014 "Gideon D'souza" wrote:
> Thanks so much Geert and Bruno for your replies:
>
>
> >>don't forget to subscribe to the specific mailing lists!
> Didn't know about this, this link is the right one?
> http://vger.kernel.org/vger-lists.html#cpufreq There isn't a list for
> the scheduler though?
Those are just the mailing lists running on vger, there are others,
you should find the right ones looking at MAINTAINERS at the root of kernel
sources (will tell you where to send mail regarding given source files,
alternatively feed path of source file to scripts/get_maintainer.pl).
> >A better start, and at least as useful is to read and review patches flowing
> > by that affect your areas of interest, test them and
> > provide feedback about possible bugs or improvements
> This is a really good idea, so far though all the patches to me look a
> little arcane, for things I barely understand. But I will keep
> looking. If I do find something, lets say a patch to the scheduler or
> some networking thing, how do you guys really test this out? How to
> you debug a scheduler? :/ How do I really "See" the system run? Put
> printk statements here are there?
There are better tools than printk(), e.g. perf, trace and similar but others
are better informed on those than I am!
printk() is useful when some specifics are needed and kgdb is overkill.
Testing if a patch works as expected is a fuzzy subject! On one hand you
need to understand what the patch does (or should do) before you can
check if it works. But just checking that it doesn't break things (for
your config/setup) can be a first step - if it breaks for you that's an
opportunity for further analysis and feedback (break can mean kernel
crash, OOPS, BUG/WARN trace or maybe just a noticeable slowdown).
Reading through some debugging threads on the mailing lists may give you
some ideas or insights and suggestions.
> >E.g. one thing I just noticed: while include/linux/compiler-gcc.h provides
> >shorthands (e.g. "__printf()") for various gcc __attribute__ macros, there
> >are still many places that don't use the shorthands, cfr. e.g.
> >"git grep 'attribute.*printf'".
> Are trivial patches like this really accepted?
Trivial patches are accepted (handled by Jiri Kosina) but I would say the
attribute macros suggested by Geert are not trivial at all!
Have a look at patches including trivial in their subject or sent to
[email protected] to get a feeling for the trivial patches, but also
have a look at Documentation/Submit* files (and all the rest in there).
Regards,
Bruno
> I've made small contributions to other OSS projects before but now I'm
> at a loss for how to study the kernel code base, what to try to
> break/change to study how the kernel works.
LXR is useful for finding code and where it goes, but the kernel is a big
project. Don't assume anyone knows how of all it works.
> Is there some simple work a newbie like me can take up? Any maintainer
> need some grunt work done? Or perhaps someone could suggest a pet
> project I could try to understand things better? (Should I be learning
> how to write device drivers?)
>
> Things that are very interesting to me so far are the KVM and the Scheduler.
Then I would fiddle with KVM and the scheduler !
Alan
So I was thinking of this hideous project (don't laugh!) at tearing
out the CFS scheduler and then rewriting a very dumb scheduler in it's
place. What do you guys think? This is of course just to understand
the scheduler better.
I just don't know how large or ridiculous this is though :)
On Mon, Jan 6, 2014 at 2:59 AM, One Thousand Gnomes
<[email protected]> wrote:
>> I've made small contributions to other OSS projects before but now I'm
>> at a loss for how to study the kernel code base, what to try to
>> break/change to study how the kernel works.
>
> LXR is useful for finding code and where it goes, but the kernel is a big
> project. Don't assume anyone knows how of all it works.
>
>> Is there some simple work a newbie like me can take up? Any maintainer
>> need some grunt work done? Or perhaps someone could suggest a pet
>> project I could try to understand things better? (Should I be learning
>> how to write device drivers?)
>>
>> Things that are very interesting to me so far are the KVM and the Scheduler.
>
> Then I would fiddle with KVM and the scheduler !
>
> Alan
On Mon, 2014-01-06 at 12:53 +0530, Gideon D'souza wrote:
> So I was thinking of this hideous project (don't laugh!) at tearing
> out the CFS scheduler and then rewriting a very dumb scheduler in it's
> place. What do you guys think? This is of course just to understand
> the scheduler better.
>
> I just don't know how large or ridiculous this is though :)
Ripping CFS apart and putting it back together in better working order
is a better project. Ripping things to bits is easy, it's the putting
things back together that can get down right interesting :)
-Mike