Being a newbie ;-) (was Re: Introducing Myself, Looking to Learn)
On Sep 03 2013, Robert P. J. Day wrote:
i'm going to jump in here since i see this question annoyingly frequently -- "i'm new to the kernel and i want to get involved and write code; how do i start?" to be blunt, if that's your starting point, you're not ready to write code for the kernel. period.
It seems to me there are a lot of reasons to ask this question, and it's not a great idea for the kernel (in the long run) to discourage newbies to the extent that "new blood" never comes in.
as vladis quite correctly points out, gone are the days when there was piles of simple coding to be done. most of the kernel is well established, solid and stable, and ongoing development is *very* advanced. in other words, there's less and less room for enthusiastic beginners. but there's more.
I think you can expect it will be a while before you write anything that's remotely worth upstreaming, except possibly drivers for obscure hardware or possibly minor bug fixes, for bug(s) that happen to replicate on your own system. That doesn't mean you can't learn. In fact, it's even possible to get paid to learn. At the moment, I'm working in a shop that ships appliances that include linux. My job is to investigate whatever goes squirrely at the kernel level, and make the system play nicely with our latest hardware. Since we're running an older version of linux, the most common result of these investigations is to find and merge an upstream patch. Another common result is to find a bug in one of our own kernel modules. Next most likely is a configuration issue. If none of these apply, we get to write the patch ourselves. If the problem affects recent kernels, we'll also submit it to LKML etc. I haven't personally had cause to submit anything yet.
it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start. it's like saying, "i really want to write a book, but i have no idea what i should write about. can you give me some ideas for a plot? and characters? and possibly an ending?" yes, it's that silly.
I tend to take this as a request for suggestions for learning exercises, or even simply where to start learning. It's a big and complex system, with layers and layers of details to deal with. I doubt "where do I start" is really a variant of "what should I develop?" (The right answer to that is pretty simple - whatever you want to have available, that isn't available ;-))
if you're a beginner, then the obvious starting point is to start reading. and read. and read. and when you're done reading, read some more. and slowly, you'll figure out what interests you most. and that's where you then spend your time.
Personally, I'd suggest playing with the code. Don't expect to produce something upstreamable. My latest ludicrous activity was reinventing part of "ftrace" ;-) I didn't mean to do that, I was just trying to get a record of [..things ftrace could have gotten me..] on a repeatedly failing system. Net result - I learnt more than I would have if I'd just used ftrace, and my coworkers are being patient about the time it's taking me to solve the original crash. (Fortunately I found a problem with the kernel configuration we were using for that appliance, as a side effect of my experiments, so the effort wasn't completely wasted ;-) And now I know about ftrace, and have ideas about extending it to do the next batch of things I want.)
rday
-- Arlie (Arlie Stephens arlie@worldash.org)
I wouldn't recommend playing with the code to ubuntu users that barely know what a terminal is. For "absolute beginners" and "novice enthusiasts" I usually recommend to start by installing Gentoo following its handbook. The Gentoo handbook is a very good learning source for beginners and it guides you through a bit of everything. And because you have to configure most of the system and compile (almost) everything from scratch, you start to get a feeling of the system as a whole. This should take a few weeks for absolute beginners. If they survive the Gentoo battle, then the dumb drivers from LDD are good next steps, because now the hacker enthusiast have some experience with (re-)compiling the kernel and with using the command line to figure out how to find causes of his problems. On Tue, Sep 3, 2013 at 5:37 PM, Arlie Stephens <arlie@worldash.org> wrote:
On Sep 03 2013, Robert P. J. Day wrote:
i'm going to jump in here since i see this question annoyingly frequently -- "i'm new to the kernel and i want to get involved and write code; how do i start?" to be blunt, if that's your starting point, you're not ready to write code for the kernel. period.
It seems to me there are a lot of reasons to ask this question, and it's not a great idea for the kernel (in the long run) to discourage newbies to the extent that "new blood" never comes in.
as vladis quite correctly points out, gone are the days when there was piles of simple coding to be done. most of the kernel is well established, solid and stable, and ongoing development is *very* advanced. in other words, there's less and less room for enthusiastic beginners. but there's more.
I think you can expect it will be a while before you write anything that's remotely worth upstreaming, except possibly drivers for obscure hardware or possibly minor bug fixes, for bug(s) that happen to replicate on your own system.
That doesn't mean you can't learn. In fact, it's even possible to get paid to learn. At the moment, I'm working in a shop that ships appliances that include linux. My job is to investigate whatever goes squirrely at the kernel level, and make the system play nicely with our latest hardware. Since we're running an older version of linux, the most common result of these investigations is to find and merge an upstream patch. Another common result is to find a bug in one of our own kernel modules. Next most likely is a configuration issue. If none of these apply, we get to write the patch ourselves. If the problem affects recent kernels, we'll also submit it to LKML etc. I haven't personally had cause to submit anything yet.
it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start. it's like saying, "i really want to write a book, but i have no idea what i should write about. can you give me some ideas for a plot? and characters? and possibly an ending?" yes, it's that silly.
I tend to take this as a request for suggestions for learning exercises, or even simply where to start learning. It's a big and complex system, with layers and layers of details to deal with. I doubt "where do I start" is really a variant of "what should I develop?" (The right answer to that is pretty simple - whatever you want to have available, that isn't available ;-))
if you're a beginner, then the obvious starting point is to start reading. and read. and read. and when you're done reading, read some more. and slowly, you'll figure out what interests you most. and that's where you then spend your time.
Personally, I'd suggest playing with the code. Don't expect to produce something upstreamable. My latest ludicrous activity was reinventing part of "ftrace" ;-) I didn't mean to do that, I was just trying to get a record of [..things ftrace could have gotten me..] on a repeatedly failing system. Net result - I learnt more than I would have if I'd just used ftrace, and my coworkers are being patient about the time it's taking me to solve the original crash. (Fortunately I found a problem with the kernel configuration we were using for that appliance, as a side effect of my experiments, so the effort wasn't completely wasted ;-) And now I know about ftrace, and have ideas about extending it to do the next batch of things I want.)
rday
-- Arlie
(Arlie Stephens arlie@worldash.org)
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Henrique Rodrigues http://www.dcc.ufmg.br/~hsr
participants (2)
-
Arlie Stephens -
Henrique Rodrigues