Hello. I am pretty new to the world of kernel hacking and I have a few
questions. I have gotten myself a copy of Linux Kernel Development by
robert love and I am also reading parts of the source code. Here are
my current questions:
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?
2) what are some bugs in the kernel that a beginner can fix?
3) is there any definitive guide to the kernel that you guys refer
most newbies to? (like Programming Perl for perl)?
4) Where's the linux kernel headed to next? What higher level features
(i.e. real features, not bug fixes) are going to implemented?
Thanks a bunch.
PS it'd be nice if you could CC me in the reply cause I don't think
I've registered properly
From: Someone Something <[email protected]>
Date: Sat, Jun 12, 2010 at 11:32:36PM -0400
> Hello. I am pretty new to the world of kernel hacking and I have a few
> questions. I have gotten myself a copy of Linux Kernel Development by
> robert love and I am also reading parts of the source code. Here are
> my current questions:
>
> 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?
>
> 2) what are some bugs in the kernel that a beginner can fix?
>
> 3) is there any definitive guide to the kernel that you guys refer
> most newbies to? (like Programming Perl for perl)?
>
> 4) Where's the linux kernel headed to next? What higher level features
> (i.e. real features, not bug fixes) are going to implemented?
>
> Thanks a bunch.
>
> PS it'd be nice if you could CC me in the reply cause I don't think
> I've registered properly
http://kernelnewbies.org/ is the place you want to start - simply read
it all, cover to cover :)
--
Regards/Gruss,
Boris.
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.
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, <[email protected]> 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.
>
>
>
Hello,
I looked through kernelnewbies.org, read some more of robert love, but
two questions still stand.
Where are the syscalls implemented and where are the header files with
their prototypes?
On Sun, Jun 13, 2010 at 1:03 PM, Someone Something <[email protected]> wrote:
> 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, ?<[email protected]> 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.
>>
>>
>>
>