How to test my patches before submitting them to LKML?

[arlie@worldash.org (Arlie Stephens)]

On Feb 07 2014, Valdis.Kletnieks at vt.edu 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 at worldash.org)