How to test my patches before submitting them to LKML?

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Feb 7 11:10:59 EST 2014


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

But yes, you should *at least* compile them, and compare the before
and after .o files to make sure they compile to the same thing.  If
you have the hardware, you should boot a kernel and try using the
device - does it still read disks?  If it's a CD/RW, does it still
burn readable disks?  And so on

> Can I boot it in a VM to test it? If yes, how to (generally and
> explicitly for my patches)? (There should be no difference if I try to
> boot it with VirtualBox vs. KVM vs. Xen, right?)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140207/5f93d358/attachment.bin 


More information about the Kernelnewbies mailing list