how to be a kernel developer ?
regatta
I want to join the Kernel community and help in developing Linux
kernel, I'm good in C,Perl and not that good in C++
is there any How-To page in how to help or how to join ? since I want
to start in basic things
Thanks
--
Best Regards,
--------------------
-*- If Linux doesn't have the solution, you have the wrong problem -*-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alejandro Bonilla
> Hi
>
> I want to join the Kernel community and help in developing Linux
> kernel, I'm good in C,Perl and not that good in C++
>
> is there any How-To page in how to help or how to join ? since I want
> to start in basic things
I can tell you one thing for sure. And that is that you will need to read a
lot and that includes the mailing list archives.
This exact question is made at least every 15 days. Did you google? You will
need to make that your Home Page.
.Alejandro
Andrew Ruder
> This exact question is made at least every 15 days. Did you google? You will
> need to make that your Home Page.
And after that, make your first google search kernelnewbies.
- Andrew Ruder
Jesper Juhl
> Hi
>
> I want to join the Kernel community and help in developing Linux
> kernel, I'm good in C,Perl and not that good in C++
>
> is there any How-To page in how to help or how to join ? since I want
> to start in basic things
>
A few things you should do :
- Take a look in the Documentation/ directory in the kernel source,
you'll find lots of valuable information there.
- Go check out http://kernelnewbies.org/
- You may also find this online source browser useful (I know I do)
http://lxr.linux.no/
- Keep a link to a LKML archive in your bookmarks and search the
archives for answers whenever you have a question - chances are good
that whatever you want to ask has been asked before and answered in
depth on the list, so it'll be in the archives. Here's one LKML
archive you can use, it goes back a few years :
http://www.ussg.iu.edu/hypermail/linux/kernel/
- Subscribe to LKML and start reading the some of the threads. A lot
can be learned by reading the bugreports and solutions that pop up on
the list, there are also often discussions on ideas, implementation
details, debugging etc etc that can be valuable. So join the list and
start listening :) ohh, and do read the lists FAQ at
http://www.tux.org/lkml/
- You may also want to join the Linux Kernel Janitors
http://janitor.kernelnewbies.org/ - they have a mailing list and a
nice TODO list of things that need doing - good place to pick a small
starting project from.
- You should also, most likely, invest in a few books on the kernel
and read them. I'd recommend these two as good ones to start with :
"Linux Kernel Development (2nd Edition), by Robert Love" and "Linux
Device Drivers (Third Edition), by Jonathan Corbet, Alessandro Rubini,
and Greg Kroah-Hartman".
- And most important of all, start reading the kernel source, and play
with the kernel source. Reading the source, making some changes and
then testing them and learning from the mistakes you make is a great
way to learn.
--
Jesper Juhl <jespe...@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl
> On 7/18/05, regatta <reg...@gmail.com> wrote:
> > Hi
> >
> > I want to join the Kernel community and help in developing Linux
> > kernel, I'm good in C,Perl and not that good in C++
> >
> The kernel is written in (mainly) C and (a little bit of) asm, no C++ in there.
>
> > is there any How-To page in how to help or how to join ? since I want
> > to start in basic things
> >
> A few things you should do :
>
A few things I forgot to mention in the first mail.
You can also help out by testing the development kernels - they need
testing by as many people as possible, so start testing the -rc
kernels and the daily git snapshots as well as the -mm kernels. Test
if they build with your usual configuration, test if they build with
"allnoconfig", "allyesconfig", "allmodconfig" and perhaps a random
config or two. Test if they boot OK, if they run OK for a longer time,
etc.
When you find a problem you can try to fix the issue yourself and send
a patch to both the mailinglist and the person responsible for the
code in question. If you are unable to fix the problem yourself, then
send a detailed bugreport to the list and the person responsible for
the code. Take a look at the REPORTING-BUGS file in the kernel source
dir and the Documentation/BUG-HUNTING file.
Helping to test pre-release kernels is a valuable effort. Run a new
kernel daily :-)
Brian O'Mahoney
Jesper Juhl wrote: ...
much useful advice, almost all of which I agree with _BUT_
please do NOT debug kernel mods on your 'main-box', where your
filesystems live. unless you like to live dangerously and make
perfect backups you don't mind spending lots of hours restoring,
unless you want to specialise in file systems, but maybe do
want to work on device drivers use a ---
sacrifical system, and, for example NFS mount everything, on
it from your main box, otherwise use a cheap local disk just
for your fs stuff
then when you blow it there is no FS damage and you don't need
to wait for FSCK, or Journal Replay, when your fs works you
can live more dangerously ;-)
You will also need a main system, and serial X-over cable,
if you want to use some of the increasing number of tools,
kdb, kgdb, kprobes .... that assume a 2 box setup
Finally, Linus personally dislikes debuggers, ... 'read the source
Luke' so patches to the mm or mainstream should be grounded an
source code analysis, not it works or xxx has 0x1234 in it.
--
mit freundlichen Grüßen, Brian.
Jan Blunck
>
> sacrifical system, and, for example NFS mount everything, on
> it from your main box, otherwise use a cheap local disk just
> for your fs stuff
>
> then when you blow it there is no FS damage and you don't need
> to wait for FSCK, or Journal Replay, when your fs works you
> can live more dangerously ;-)
>
Or try qemu/bochs for your laptop, Xen for your desktop and z/VM for
your mainframe ;)
Jan
Jesper Juhl
^^^
That's a bad habbit - makes it impossible to send a
proper reply back to all the recipients. LKML is a public list, please
use To: and CC: so it's possible to reply to the proper people, and
don't trim the CC: list please.
> Jesper Juhl wrote: ...
>
> much useful advice, almost all of which I agree with _BUT_
>
> please do NOT debug kernel mods on your 'main-box', where your
> filesystems live. unless you like to live dangerously and make
> perfect backups you don't mind spending lots of hours restoring,
>
You are right. A sacrificial box or at least proper backups of any
important stuff is important. I didn't write that since I figured it
to be obvious, but I guess I should have spelled it out anyway. Thank
you for making that bit clear :-)
--
Jesper Juhl <jespe...@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html