Re: Introducing Myself, Looking to Learn
Hi All, It's good to start with LDD3 for beginner, But we end up just compiling the modules from the examples. Most of us don't now how to test these modules. But we can get learn the basic of module programming. Real challenge are in the kernel source tree. For example if we have a wireless/Ethernet card in laptop, you can go thought the changes that are happing with your driver with respect to old kernel. Also try to understand the patches that are been currently discuss in the mailing list. Understand the discussion that take place in mail chains, these will help clearing you concepts. Understand the protocol used by the driver and how new support can be added to it. Integrating with the original developer will give you new thought. Also user space is very good area to explore and very important one. If you just load the driver but don't configure it correctly It will not work to it's potential. How we configure you driver, where are the configuration files. Try to so all the configuration chances manually, this will help a lot. Try to trace the functionality from the user space IOCtl call to driver, modparams etc. We always try to use the configuration that's available in the internet. We do not go beyond that configuration and try to experiment on new values, May be we should do that and see how it works or behaves. One more thing getting to compile a custom configured kernel for you PC is important step. Having knowledge of GIT is must now a days. And you will become you own mentor for that driver. -Anand Moon On Monday, October 28, 2013 4:11 PM, Matthias Brugger matthias@gmail.com wrote: 2013/9/3 Robert P. J. Day rpj...@crashcourse.ca: On Tue, 3 Sep 2013, valdis.kletni...@vt.edu wrote: On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) 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. 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. at the very least, you should have an idea of what part of the kernel interests you most. if you can't even identify which major subsystem -- networking, USB, video, etc. -- you want to work on, you aren't even *remotely* ready to start writing code. 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. 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. Basically my answer to this kind of questions is, to start reading LDD3 [1] try to figure out what have changed and try to get the source code examples work with a newer kernel [2]. [1] http://lwn.net/Kernel/LDD3/ [2] https://github.com/martinezjavier/ldd3 Cheers, Matthias rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/ Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- motzblog.wordpress.com ___
Re: Introducing Myself, Looking to Learn
2013/9/3 Robert P. J. Day rpj...@crashcourse.ca: On Tue, 3 Sep 2013, valdis.kletni...@vt.edu wrote: On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) 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. 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. at the very least, you should have an idea of what part of the kernel interests you most. if you can't even identify which major subsystem -- networking, USB, video, etc. -- you want to work on, you aren't even *remotely* ready to start writing code. 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. 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. Basically my answer to this kind of questions is, to start reading LDD3 [1] try to figure out what have changed and try to get the source code examples work with a newer kernel [2]. [1] http://lwn.net/Kernel/LDD3/ [2] https://github.com/martinezjavier/ldd3 Cheers, Matthias rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- motzblog.wordpress.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? Here's a little something about myself, I'm fairly good with C, Python and Java and have programmed using threads with Python. I've been using Linux via the command line for a long time now. As for the OS and kernel level stuff, I don't have a lot of experience, but am enthusiastic to learn, and am working on it. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I do realize that contributing to the kernel would not be an easy task, and I must know a lot before I can contribute actual code. But still, I would be happy to. My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. I should be able to minimize the incomprehensible part soon, there's a lot to catch up with... Thanks for the advice. Varad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
Varad, I have external sata to usb3 adapter that is not supported by the kernel. I'm willing to buy one for someone willing to get the kernel support done. This is my second offer. No takers the first time. Fyi: I expect no true code is needed, just updating a pid / vid table somewhere. I don't know the usb driver stack so I have no idea where said table is. Fyi2: I tend to focus on filesystems recently so diving into usb is not a goal of mine. Greg Rakesh Ganimineni everfriendlyrak...@gmail.com wrote: I would suggest you to fix on a module and start following what are the bugs in it and see if you can fix it or try understand what others fix. From: Arlie Stephens Sent: 4/9/2013 7:08 To: Varad Gautam Cc: kernelnewbies@kernelnewbies.org Subject: Re: Introducing Myself, Looking to Learn Hi Varad, On Sep 04 2013, Varad Gautam wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? If you don't have good practical understanding of concurrency, you might want to do yourself a favour and do some work with a large multi-threaded program until you've got practical experience with race conditions, lock contention, and deadlocks. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I have also subscribed to the LKML, but find it completely incomprehensible! My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. Beyond that, there's learning you need to do. As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Pick one that you actually run - that way you're set up to try out the results of your experiments, and more likely to encounter some problem that motivates you to attack it. Personally I'd prefer not to be testing on my development system [hate it when that's unstable], but if you aren't playing with hardware, VMs make great test environments. Beyond that, my advice would be to do something trivial. How about a kernel module that prints Hello world? It's useless, but you'll start internalizing the build system. Then do something else trivial, that let's you poke the kernel somewhere else. Eventually either it'll start making sense, and your ambitions will increase - or you'll decide you aren't having fun and try somethign else. -- Arlie (Arlie Stephensar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Wed, 04 Sep 2013 00:59:03 +0530, Varad Gautam said: I have also subscribed to the LKML, but find it completely incomprehensible! As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Depends what you're trying to do. But please note that if you're finding it *completely* incomprehensible, you're probably not going to be able to make any real code contributions until you get up to speed. Yes, there's some threads on lkml that there's only a dozen people who will actually understand - but most discussion threads on lkml are ones that anybody who's able to do kernel hackind should be able to at least follow and figure out what's going on. Yes, the ability level needed to hack on the kernel and get code upstreamed *has* gone up in the last 5 years or so. pgppRH1eMimKv.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
But please note that if you're finding it *completely* incomprehensible, you're probably not going to be able to make any real code contributions until you get up to speed. Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Is there something I should start with, which would help me bring myself at par? Thanks. Varad ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) (Hint - we probably need more testers than we need more coders. Every single person that runs linux-next kernels and does QA and reports issues is a help) pgpCcqq9mF7Tj.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Tue, 3 Sep 2013, valdis.kletni...@vt.edu wrote: On Wed, 04 Sep 2013 02:05:42 +0530, Varad Gautam said: Hi Vladis! Thanks for replying. I think I would be fine with writing real code once I figure out what goes where. Well, assuming you have a background as a professional or very serious amateur programmer, *and* you have a *particular* drive to do something specific. There's still a lot of code being added by amateurs who have some weird USB device that doesn't have a driver and so on - but there's less and less room for beginners that just want to hack code and don't care where. Data structures and algorithms have gotten more complex, the locking is more fine-grained and subtle - gone are the days you could just take the Big Kernel Lock and not worry, now you ofteh have to understand stuff like RCU locking. So you might want to stop and ask yourself *why* you want to write code for the kernel. :) 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. 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. at the very least, you should have an idea of what part of the kernel interests you most. if you can't even identify which major subsystem -- networking, USB, video, etc. -- you want to work on, you aren't even *remotely* ready to start writing code. 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. 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. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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 ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
On Tue, Sep 3, 2013 at 4:29 PM, Varad Gautam varadgau...@live.com wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. I have also subscribed to the LKML, but find it completely incomprehensible! As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Hi, If you are an absolute beginner, I recommend you to start studying and hacking a small O.S., like the xv6: http://pdos.csail.mit.edu/6.828/2012/xv6.html http://pdos.csail.mit.edu/6.828/2012/xv6/book-rev7.pdf If you need a background on the low level, I suggest you to read this: http://download.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf -- Augusto Mecking Caringi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Being a newbie ; -) (was Re: Introducing Myself, Looking to Learn)
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 ar...@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 ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Henrique Rodrigues http://www.dcc.ufmg.br/~hsr ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Introducing Myself, Looking to Learn
Hi Varad, On Sep 04 2013, Varad Gautam wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? If you don't have good practical understanding of concurrency, you might want to do yourself a favour and do some work with a large multi-threaded program until you've got practical experience with race conditions, lock contention, and deadlocks. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I have also subscribed to the LKML, but find it completely incomprehensible! My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. Beyond that, there's learning you need to do. As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Pick one that you actually run - that way you're set up to try out the results of your experiments, and more likely to encounter some problem that motivates you to attack it. Personally I'd prefer not to be testing on my development system [hate it when that's unstable], but if you aren't playing with hardware, VMs make great test environments. Beyond that, my advice would be to do something trivial. How about a kernel module that prints Hello world? It's useless, but you'll start internalizing the build system. Then do something else trivial, that let's you poke the kernel somewhere else. Eventually either it'll start making sense, and your ambitions will increase - or you'll decide you aren't having fun and try somethign else. -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Introducing Myself, Looking to Learn
I would suggest you to fix on a module and start following what are the bugs in it and see if you can fix it or try understand what others fix. From: Arlie Stephens Sent: 4/9/2013 7:08 To: Varad Gautam Cc: kernelnewbies@kernelnewbies.org Subject: Re: Introducing Myself, Looking to Learn Hi Varad, On Sep 04 2013, Varad Gautam wrote: Hi! I want to start working on the Linux kernel but am an absolute beginner. I am currently on my way through Robert Love's Linux Kernel Development and need help with finding something I can work on to get a hang of what it's like. How much of a beginner are you? In particular, how much do you know about operating system kernels in general? And how much multi-threaded programming have you done, in situations where you have to manage your own locking? If you don't have good practical understanding of concurrency, you might want to do yourself a favour and do some work with a large multi-threaded program until you've got practical experience with race conditions, lock contention, and deadlocks. Linux is a fairly mature monster. This means that the simple outlines of what all OSes do tend to be obscured by layers of complexity. That's one some folks use BSD for their OS-kernel classes. You'll be doing more digging in linux. Will you be comfortable with that? I have also subscribed to the LKML, but find it completely incomprehensible! My question would be incomprehensible how? There's a lot of shared context, which you won't have, and diffs aren't the best way to learn what's in a piece of code. That level of incomprehensible makes sense to me. Beyond that, there's learning you need to do. As a beginner, would it be better to work with the kernel of a specific OS (I'm running Ubuntu), or work on the upstream kernel? Pick one that you actually run - that way you're set up to try out the results of your experiments, and more likely to encounter some problem that motivates you to attack it. Personally I'd prefer not to be testing on my development system [hate it when that's unstable], but if you aren't playing with hardware, VMs make great test environments. Beyond that, my advice would be to do something trivial. How about a kernel module that prints Hello world? It's useless, but you'll start internalizing the build system. Then do something else trivial, that let's you poke the kernel somewhere else. Eventually either it'll start making sense, and your ambitions will increase - or you'll decide you aren't having fun and try somethign else. -- Arlie (Arlie Stephens ar...@worldash.org) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
