On Feb 07 2014, Valdis.Kletnieks@xxxxxx wrote: > > On Fri, 07 Feb 2014 18:30:46 +0100, Matthias Beyer said: > > > So you would say, I should start patching non-hardware driver code, > > FS for example, to get my feet wet with the kernel? > > You might want to take a step back, be a bit more meta, and ask yourself > why, exactly, you want to do kernel hacking at all. If there isn't an > obvious part of the kernel that interests you, maybe kernel hacking isn't > where you should be. Personally, I'm annoyed by coding cruft. If I thought I could upstream clean up changes successfully, I'd make a lot of them ;-) It was probably a good thing to warn the OP that upstreaming such changes is going to be extremely difficult. But _making_ and _testing_ that kind of changes is as good a way to get one's hands dirty as any, and better than some. And IMO, getting one's hands dirty - preferably with more than just trivial changes or isolated add-ons - is the best way to really learn. Yes, you need to walk before you can run. And (eventually) getting feedback will teach you things you might not have learned any other way. But making changes, testing them, and *not* upstreaming most of them, can teach you a lot. Personally, I have 2 goals: - get paid - get good enough at linux to successfully play in the core kernel (successful == get changes accepted routinely, etc. etc.) Doing the former mostly just requires finding the right upstream patch to apply to our product's elderly kernel, and/or explaining to developers why their design choices are creating performance issues. But even getting good at that limited goal is enhanced by simply mucking around, writing things that may well duplicate existing functionality, making big design changes beyond my present skill level, and generally getting close and personal with the source code. I wish I had more time to do that, rather than chasing down (e.g.) the latest thing in creative misuse of the hugetlbfs ;-) Of course when I start upstreaming stuff, it'll probably be obvious fixes for trivial bugs, and/or hardware enablement. I know my skill and reputation level ;-) And the less I get time to just mess around with code, the less likely I'll achieve the second goal. Given that I'm not doing much on my own time, I'd say I'm not all that dedicated to it ;-( -- Arlie (Arlie Stephens arlie@xxxxxxxxxxxx) _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
