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 22:11:19 +0200	[thread overview]
Message-ID: <20140905201119.GG28079@fu> (raw)
In-Reply-To: <20140905185445.GA24174@kroah.com>

On 05-09-2014 11:54:45, Greg KH wrote:
>
> > 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.

Well, there comes git into play: If I do a build for
each branch I have, this takes a huge amount of time for all
patchsets, as when checking out another patchset, files get changed.

At this very moment, I have 15 patchsets ready for submission and one
I'm working on. Doing

    for ps in patchsets; do make -j 8; done

still takes a lot of time then. That's why I asked the question.

> 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.

Of course, I'm already doing this.

>
> > 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.

This sounds like the work I'm doing is a waste of time? Shall I
continue with my patches?

If not, I will find another staging driver I can work on, so no
problem! :-)

>
> hope this helps,

Indeed it does. I did not expect to get an answer directly from you!
Thank you a lot!

-- 
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/db0f8311/attachment.bin 

  parent reply	other threads:[~2014-09-05 20:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 16:42 Better testing when patching divers/staging/ - howto? Matthias Beyer
2014-09-05 18:54 ` 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 [this message]
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=20140905201119.GG28079@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.