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
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)
On Tue, 3 Sep 2013, Valdis.Kletnieks@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 ========================================================================
Hi! On 17:44 Tue 03 Sep , Robert P. J. Day wrote: ...
it's somewhat absurd to say you want to get involved in kernel development, then ask *others* where you should start.
I guess it sounds absurd because he missed how open source development works: 1) Find something you do not like. 2) Try to understand what is going on. 3) Try to think of ways to solve it. 4) Ask for opinions. 5) Implement your solution. 6) Post it. Depending on how others react you might decide to redo parts or even start from scratch (or maybe even abandoning it). It could also happen that somebody else takes your idea and solves it in a different way. Bad things could happen as well, like everybody ignoring you because they do not care about your problem. This is in contrast to school/work environments where others tell you what you have to do.
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.
Isn't this called "writer's block"? To me this does not sound like a silly thing to say at all. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com
On Wed, 04 Sep 2013 07:22:14 +0200, michi1@michaelblizek.twilightparadox.com said:
1) Find something you do not like.
Exactly. This is the point a lot of people miss. Personally, I mostly stick to "badly written Kconfig entries" and "stuff in linux-next that makes my Dell laptop misbehave", because that's stuff I can actually test/report/fix, and stuff that ticks me off. ;)
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.
Isn't this called "writer's block"? To me this does not sound like a silly thing to say at all.
Writer's block is when you can't find a rhyme for the 23rd line, or can't figure out how to make your villain drop out in chapter 5 so he can re-appear in chapter 9. If you need ideas for plot, characters, and ending, you're not a writer. Horror writer Steven King was once asked "Why do you write such dark scary stuff?". He replied "What makes you think I have any choice in the matter?" Now that dude is a *writer*. And quite frankly, unless somebody have similar feelings about coding, they probably shouldn't be hacking the kernel.
Hello all, I am also a newbie that intends to get her way into kernel development. Something about me: I have some experience as software tester. My question is: do you thing that systematically testing the kernel may be the way to go for me to get into the Linux kernel? Maybe joining the Linux Test Project? I am mainly (but not only) interested in virtualization because I am somewhat familiar with it and I find it necessary and interesting. I know I have a lot to learn, and I noted all the advice you gave Varad. If you have any further advice of any kind, I will really thank you for it. María. On 4 September 2013 15:41, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 04 Sep 2013 07:22:14 +0200, michi1@michaelblizek.twilightparadox.com said:
1) Find something you do not like.
Exactly. This is the point a lot of people miss.
Personally, I mostly stick to "badly written Kconfig entries" and "stuff in linux-next that makes my Dell laptop misbehave", because that's stuff I can actually test/report/fix, and stuff that ticks me off. ;)
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.
Isn't this called "writer's block"? To me this does not sound like a silly thing to say at all.
Writer's block is when you can't find a rhyme for the 23rd line, or can't figure out how to make your villain drop out in chapter 5 so he can re-appear in chapter 9. If you need ideas for plot, characters, and ending, you're not a writer.
Horror writer Steven King was once asked "Why do you write such dark scary stuff?". He replied "What makes you think I have any choice in the matter?"
Now that dude is a *writer*.
And quite frankly, unless somebody have similar feelings about coding, they probably shouldn't be hacking the kernel.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 03 Sep 2013 17:44:30 -0400, "Robert P. J. Day" said:
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.
If they want to be productive right up front, they should learn how to get a copy of the linux-next tree, how to update it, and build/run kernels from it. We can always use more testers of code before it gets released - it makes Greg KH's work with stable kernels a lot easier if we catch the bugs before they are officially released. Oh, and if people want to learn the kernel, "figure out what in linux-next broke *this* time" is a good way to do it - I never seem to hit 2 bugs in the same secion of the kernel in a row. Oh, and build those kernels with lockdep testing enabled - it finds a lot of bugs, and figuring out why a given lockdep report is a problem (or a false positive) is *great* training for understanding locking.
2013/9/3 Robert P. J. Day <rpjday@crashcourse.ca>:
On Tue, 3 Sep 2013, Valdis.Kletnieks@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
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.bgg@gmail.com> wrote: 2013/9/3 Robert P. J. Day <rpjday@crashcourse.ca>:
On Tue, 3 Sep 2013, Valdis.Kletnieks@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
participants (7)
-
Anand Moon -
María Soler Heredia -
Matthias Brugger -
michi1＠michaelblizek.twilightparadox.com -
Robert P. J. Day -
Valdis.Kletnieks＠vt.edu -
Varad Gautam