Better testing when patching divers/staging/ - howto?

[greg@kroah.com (Greg KH)]

On Fri, Sep 05, 2014 at 06:42:41PM +0200, Matthias Beyer wrote:
> Hi,
> 
> I do big (cleanup) changes in
> 
>     drivers/staging/bcm/
> 
> Recently, I managed to piss off greg-kh by sending in a patch that
> broke the build[0].
> 
> After some time off, I want to re-start doing patches in this driver
> and of course do better!

Try test-building your patches, that's a good start :)

> What I do by now:
> 
>     1) Patching until my task is done. For example outsourcing stuff
>     from functions in a file.
> 
>     2) Before sending my patchset, compiling the appropriate patches
>     like so:
> 
>         make drivers/staging/bcm/

Don't also forget a general 'make' for the whole tree, otherwise
undefined symbols that you might have deleted from the module will not
show up if you just build one subdirectory.

>     3) If it builds, generating patches, checking them and sending
>     them.
> 
>         git format-patch gregkh-staging/staging-next..HEAD # more args
>         scripts/checkpatch.pl ./00*
>         git send-email # some args
> 
> The error mentioned in [0] wasn't thrown when doing 2).

Because you only built the subdirectory...

> My question to you: How to do better? How to test the patches even
> more? By building a whole kernel with them?

Yes.

> Is that what greg-kh did and where the error he mentioned in [0] comes
> from?

Yes.

> Or is there a test-suite-like thing around I just didn't discover yet?

Nope.

> I do not have that much ressources to always build a full kernel for
> only one patchset, so would it be okay to (locally) merge my patchsets
> into a temporary branch and build a (allyesconfig) kernel out of all
> my patchsets?

Why?  If you just change one file, 'make' will only rebuild that one
file.

Also do a faster make, with the -j option.  Pass in 2x the number of CPU
cores you have, so if you have 2 cores do:
	make -j4

to get a _much_ faster build.

> In addition, I do not have the appropriate hardware to actually _run_
> the code. I always state this in my patchset messages, of course!

It would be great if you could find some hardware, I really want to just
delete this driver as no one seems to have the hardware anymore.
You can only clean up just so much stuff without having to start to
change the logic in the code, and you need the hardware to test that.

hope this helps,

greg k-h