Message-ID: <20766.1276435765@localhost>
Date:	Sun, 13 Jun 2010 09:29:25 -0400
From:	Valdis.Kletnieks@...edu
To:	Someone Something <fordhaivat@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Help for a newbie

On Sat, 12 Jun 2010 23:32:36 EDT, Someone Something said:

> 1) when you write userland apps, you usually include stuff like :
> sys/types.h or errono.h where are all these defined in the linux
> kernel because I would like to add a few syscalls of my own?

Look at any source files already in the kernel, they'll give you a good
hint of where the .h files are.  Keep in mind that in the kernel, we
tend to #include a lot of header files, depending on what exactly is needed.

Regarding adding syscalls - step 0 is doing a proper design and making sure
that in fact you need a new syscall.  What features do you want to add, and
why do they need syscalls?

It's usually a bad idea to add syscalls unless you *really* need to - most
of the time creating a loadable kernel module is a better idea (among other
things, you can compile a module against a distro kernel without rebuilding
the entire kernel, you can't do that with a syscall).

> 2) what are some bugs in the kernel that a beginner can fix?

Unfortunately, we're victims of our own sucess here.  There really aren't many
long-standing bugs left that a beginner can fix.  If you follow the linux-next
or Andrew Morton's -mm kernel, you'll find the occasional typo or messed up
code that has an #ifdef backwards so it doesn't build for all configs, and so
on.  But in general, if the bug has been there more than 12 hours or so, it
usually means that it's a nasty ugly mess and will require some real work to
fix.

That isn't to say that the developers don't appreciate all those little
one-line patches to make stuff work in your config that they didn't test.
They appreciate those a *lot*.  I just can't point you at any because the list
will be different by the time you read this mail.

> 3) is there any definitive guide to the kernel that you guys refer
> most newbies to? (like Programming Perl for perl)?

Robert Love's book and "Linux Device Drivers, 3rd ed" are both pretty good
overviews, although somewhat dated because the code is a moving target.
Once you got a handle on the major data structures, it's really "Use The
Source, Luke" time.

> 4) Where's the linux kernel headed to next? What higher level features
> (i.e. real features, not bug fixes) are going to implemented?

Well, I really can't say anything definite other than "read LKML or at least a
weekly scan of the Subject: lines to see what's new".  It's going to be the
same as it has for the last few years - code will be merged when it's written
by somebody who's scratching an itch.  We'll eventually merge *something* for
the Android power-management issue (because we really *do* need a solution in
that area), new file systems will be merged, device drivers will be written,
and so on. What will go in for 2.6.36 and later releases pretty much depends on
what code people feel motivated to write for submission.



Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists