kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: mail@beyermatthias.de (Matthias Beyer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: How to test my patches before submitting them to LKML?
Date: Fri, 7 Feb 2014 18:30:46 +0100	[thread overview]
Message-ID: <20140207173046.GX27070@fu.3gs> (raw)
In-Reply-To: <22342.1391789459@turing-police.cc.vt.edu>

On 07-02-2014 11:10:59, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 07 Feb 2014 16:31:04 +0100, Matthias Beyer said:
> 
> > I'm currently working on some stylefix-patches for
> > drivers/cdrom/cdrom.c and I'm slowly getting to a point where they
> > seem to be ready. How to test my patches?
> 
> Note that some maintainers don't like accepting style fix patches,
> because they are of the opinion that there's 2 basic cases.
> 
> The first is that somebody else is doing active work on the driver, and
> this causes merge conflicts when your patches and theirs collide.
> 
> The second is where the code is already stable, and you hit this:
> 
> > I know I should compile them at least, to be sure they build. But how
> > can I test if the code (still) works (the way it is expected to)?
> 
> Yes, it's possible you break some stable code this way.  So the maintainer
> may not want them unless you're doing it as preparation for actual work
> on the driver...
> 

That's true. But how can I get my feet wet _without_ running into the
issue of possibly breaking something? Of course, with testing and all
the stuff... but I'm still a newbie working on running code! I cannot
create a new driver from scratch, as I do not have the capabilities!

> The problem is that whether it's VirtualBox, KVM, or Xen, you're testing
> against a virtualized device, not real hardware.  This isn't as big an issue if
> you're doing filesystem work, or the memory manager or scheduler, but can be a
> problem if you're testing a hardware driver...

So you would say, I should start patching non-hardware driver code,
FS for example, to get my feet wet with the kernel?

-- 
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: 836 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140207/5b8e8ee8/attachment.bin 

  reply	other threads:[~2014-02-07 17:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-07 15:31 How to test my patches before submitting them to LKML? Matthias Beyer
2014-02-07 16:10 ` Valdis.Kletnieks at vt.edu
2014-02-07 17:30   ` Matthias Beyer [this message]
2014-02-07 18:30     ` Valdis.Kletnieks at vt.edu
2014-02-07 19:05       ` Robert P. J. Day
2014-02-07 20:51       ` Arlie Stephens
2014-02-07 23:46         ` Valdis.Kletnieks at vt.edu

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=20140207173046.GX27070@fu.3gs \
    --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 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).