On 25/07/06, Hari Prashanth <annabase@xxxxxxxxxxx> wrote:
Dear All,
I am new to this group. I am very enthusiastic about linux and i
started using linux 4 years ago. I was working with it for day to
applications ie for home use. Now i wanted to study the implementation
of the complete linux.
I believe you are mainly talking about the kernel since you are
posting to the kernelnewbies list.
I have installed Fedora Core 4 in my Laptop. Can
anyone please advise me where to start from and how do i go about it?
Can anyone suggest a small project which i can do for gaining
experience. Can any starter join me to carry out the project?
This is something that get asked a lot on this list. If you search the
archives you'll find a lot of good information.
I recently answered a similar mail send to me in private, so instead
of writing up a new reply for you I'll just quote most of what I told
that other person - so, when reading the following part of the mail,
please keep in mind that it was originally written as a reply to
someone else, so some of it may not be quite what you were thinking
of.
Start reading the LKML (Linux Kernel Mailing List). Read all sorts of
different threads and gradually you'll pick up on the lingo - you'll
probably also learn a thing or two about the kernel at the same time
(and it's a great way to pick up info on things that need doing - if
you see something discussed that you think you can fix, then you can
jump right in and offer to fix it - but don't forget to let people
know if you give up so someone else can take over).
Don't worry if you don't understand everything at first, just start
following the list and pick up the bits you can.
(ohh and when you post to the list, don't top-post).
You can also take a look at
http://www.kernelnewbies.org/KernelGlossary for a list of the most
common terms with short explanations.
Let me see if I can give you some ideas on easy things to start with.
There are lots of things that need doing and some of them don't even
require programming skills.
You can help improve the documentation. Even a simple thing such as
fixing spelling errors or correcting grammar is worth doing.
It's also helpful if you dig for Kconfig help entries that are blank,
work out what the config option is for and write a patch that add a
suitable help entry.
You can also help out by simply running the daily git snapshots and/or
latest -mm kernels on a regular basis. Use them as your every-day
kernel, watch for regressions and bugs (build them with some of the
debugging options enabled). Then if/when you spot a regression or bug
(make it a habbit to check dmesg once in a while), write up a detailed
bug report and submit it to the list and relevant maintainers. That's
a *very* useful thing to do regardless of anything else you may do.
Of course you can also try to actively provoke bugs by stressing
different areas of the kernel or just by trying out unusual things.
Personally the first thing I do every morning when I turn on my PC is
fetch the latest git snapshot from kernel.org, build it, install it,
boot it and then use that as my kernel for the day (ok, maybe not
every day, but at least I do it every other day).
It's of-course perfect if you are able to fix the bug you found and
can submit a patch along with your bugreport, but it's in no way
required, and if you can just submit a detailed well written bug
report then that is worth it's weight in gold.
You can also take a look at the Kernel janitors TODO list -
http://janitor.kernelnewbies.org/TODO - it lists a lot of minor things
that need to be done. A lot of it is pretty trivial and tedious work,
but it's often a great place to find some beginners projets to cut
your teeth on.
You can also go digging through the source looking for files that
don't conform to the official kernel CodingStyle (see
Documentation/CodingStyle for details). Then clean up the file so it
does conform (hint: scripts/lindent is helpful to get started but
don't assume it gets everthing right, it needs manual verification and
correction).
Another easy thing to get started with is simply build a lot of
kernels, log all the output from the build process, look for any
warnings or errors that show up, pick one at a time, investigate *why*
the compiler warns or errors out, create a patch to fix the problem,
submit it, listen to the feedback you get (possibly correct the
patch), then move on to the next warning/build error.
"make randconfig" is useful to generate a bunch of random configs to
build and is an easy way to gather lots of warnings and errors to
investigate (just make sure you don't waste time on configs that are
generated with CONFIG_EXPERIMENTAL set - skip those).
This is useful work.
As you get more experienced you can try to get involved in projects
discussed on the LKML (you should be following this list regularly by
now) that interrest you.
I'd say doing a little bit of all of the above is a good way to start.
It'll let you get aqainted with a lot of different parts of the
kernel. It'll let you get comfortable with submitting patches and
working with other developers and you'll be doing useful work fairly
quickly.
Some more general advice;
Before you do anything else make sure you have (as a minimum) read the
following documents :
From the kernel source:
README
REPORTING-BUGS
Documentation/HOWTO
Documentation/Changes
Documentation/BUG-HUNTING
Documentation/CodingStyle
Documentation/SubmittingPatches
Documentation/SubmittingDrivers
Documentation/applying-patches.txt
Online:
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
http://linux.yyz.us/patch-format.html
I should probably also stress the importance of keeping up-to-date
backups of any important data you have on your machine or using a
sepperate development machine when running development kernels.
Although bugs that end up eating your files and/or filesystems are
rare these days they still happen from time to time, so just make sure
that that's not a problem.
Also, when running development kernels you *will* run into Oops'es
(crashes) more often than when only running the stable kernels. And
when you do, capturing the Oops output is very important, but often
the system will be in no state to write it to your logs or you may be
in X and don't even see it get printed on the console or the system
just hangs.
Be prepared to capture bugs, either by running a serial console on
another machine where you can record the Oopses when they happen or
use netconsole (useful, but not as reliable as serial console in my
experience).
If you have a printer, then console on line printer can also be useful. If
you can do none of those, then taking a photo of the screen with the
Oops on it or writing it down by hand (*all* of it) will have to do.
You probably also want to make sure your kernels have magic sysrq
support build in so you can (at least attempt to) do an emergency
flush, and unmount of your filesystems when the box hangs followed by
an emergency reboot... That's a lot better than just hitting the power
button. sysrq can also be used to capture stack traces for running
programs, get memory dumps etc. See Documentation/sysrq.txt for
details.
Also, please always submit patches in plain text generated with "diff -up"
inline in a plain-text email. No HTML mails. No attachments.
Plain text with patch inline (and do test send the patches to your
self first the
first few times and try applying them to make sure your mailer doesn't
mangle them).
Also always include a diffstat and a Signed-off-by: line (the above
documents have details on this).
You also don't want to mix different types of changes in the same
patch. If for example you have been doing a warning fix as well as a
general CodingStyle cleanup of a file, then don't include both in the
same patch but submit two distinct patches instead (in 2 emails) that
each do just
one thing.
Also always include in the description of your patch not just what it
does but also *why* it does it.
At some point in time you probably also want to learn how to use git -
http://git.or.cz/ - which is what Linus and lots of other core
developers use to manage the kernel source.
Some additional pages to visit online for more info etc :
http://lwn.net/Kernel/LDD3/
http://www.freesoftwaremagazine.com/articles/drivers_linux
http://kerneltrap.org/node/3648
http://lkml.org/
http://sosdg.org/~coywolf/lxr/source/
http://lxr.free-electrons.com/
http://kerneltrap.org/
http://linux.yyz.us/git-howto.html
http://www.catb.org/esr/faqs/smart-questions.html
I hope this was a useful reply. If you have more questions etc, feel
free to ask.
--
Jesper Juhl <jesper.juhl@xxxxxxxxx>
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
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
