Re: Help for a newbie

[Someone Something]

Thanks for the very thorough reply. As for the syscalls, I just wanted
to add one that gave you the task descriptor struct for the init
process, just for fun. I would also like to start writing kernel
modules. I'm not exactly experienced with hardware so I'll probably
put off device drivers for a while.

Thanks a lot,

Dhaivat

On Sun, Jun 13, 2010 at 9:29 AM,  <Valdis.Kletnieks@xxxxxx> wrote:
> 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.
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/