All of lore.kernel.org
 help / color / mirror / Atom feed
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 

             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.