From: mail@beyermatthias.de (Matthias Beyer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Better testing when patching divers/staging/ - howto?
Date: Fri, 5 Sep 2014 18:42:41 +0200 [thread overview]
Message-ID: <20140905164241.GF28079@fu> (raw)
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!
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/
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).
My question to you: How to do better? How to test the patches even
more? By building a whole kernel with them? Is that what greg-kh did
and where the error he mentioned in [0] comes from? Or is there a
test-suite-like thing around I just didn't discover yet?
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?
In addition, I do not have the appropriate hardware to actually _run_
the code. I always state this in my patchset messages, of course!
I hope you guys can help me, as doing kernel patches is a nice hobby
to me and I would like to continue.
[0]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-August/057437.html
--
Mit freundlichen Gr??en,
Kind regards,
Matthias Beyer
Proudly sent with mutt.
Happily signed with gnupg.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140905/1019fc30/attachment.bin
next reply other threads:[~2014-09-05 16:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 16:42 Matthias Beyer [this message]
2014-09-05 18:54 ` Better testing when patching divers/staging/ - howto? Greg KH
2014-09-05 19:09 ` Valdis.Kletnieks at vt.edu
2014-09-05 20:02 ` Mandeep Sandhu
2014-09-05 20:11 ` Greg KH
2014-09-05 20:31 ` Mandeep Sandhu
2014-09-05 20:11 ` Matthias Beyer
2014-09-05 22:17 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140905164241.GF28079@fu \
--to=mail@beyermatthias.de \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.