Re: Help for a newbie

[Someone Something]

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 <fordhaivat@xxxxxxxxx> 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,  <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/