From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Better testing when patching divers/staging/ - howto?
Date: Fri, 5 Sep 2014 15:17:37 -0700 [thread overview]
Message-ID: <20140905221737.GB1533@kroah.com> (raw)
In-Reply-To: <20140905201119.GG28079@fu>
On Fri, Sep 05, 2014 at 10:11:19PM +0200, Matthias Beyer wrote:
> 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.
What is a "patchset" in this context? You need to test the build at
_every_ patch, to not do so isn't ok.
> > > 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! :-)
I can't tell anyone what to work on, but again, I really want to just
delete the driver as it is quite horrid. If you don't have the hardware
for it, and you don't want to get it, I suggest working on something
else that actually has a chance of getting merged to the proper portion
of the kernel tree.
No one who originally had the hardware does anymore, and wimax is all
but dead, so it is not something anyone seems to care about.
thanks,
greg k-h
prev parent reply other threads:[~2014-09-05 22:17 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
2014-09-05 22:17 ` Greg KH [this message]
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=20140905221737.GB1533@kroah.com \
--to=greg@kroah.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).