How to test my patches before submitting them to LKML?

How to test my patches before submitting them to LKML?

[Matthias Beyer]

Hi,

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?

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)?

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?)

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

How to test my patches before submitting them to LKML?

[Valdis.Kletnieks at vt.edu]

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 

How to test my patches before submitting them to LKML?

[Matthias Beyer]

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 

How to test my patches before submitting them to LKML?

[Valdis.Kletnieks at vt.edu]

On Fri, 07 Feb 2014 18:30:46 +0100, Matthias Beyer said:

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

You might want to take a step back, be a bit more meta, and ask yourself
why, exactly, you want to do kernel hacking at all.  If there isn't an
obvious part of the kernel that interests you, maybe kernel hacking isn't
where you should be.

For instance, I mostly pay attention to "stuff that drops in linux-next
and breaks my laptop", and "stuff that will matter when it hits distro
enterprise kernels" (like a patch set a while ago that had implications
for stuff like malware scanners, compliance issues, and HSM storage).

It's sort of like when people learn I have 3 guitars, and they reply
"Oh, I've always wanted to play guitar".  And I tell them "No, you probably
just want to be able to *say* you play guitar.  If you *really* wanted to
play guitar, you'd have found a used one for $95 on Craigslist or something,
and taught yourself, and figured out where you can play at 2AM without
pissing anybody off".

So ask yourself - Why an I trying to do kernel hacking?  Once you know the
answer to that, you'll know what part of the kernel (if any) you should
be looking at.
-------------- 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/bd720fd1/attachment.bin 

How to test my patches before submitting them to LKML?

[Robert P. J. Day]

On Fri, 7 Feb 2014, Valdis.Kletnieks at vt.edu wrote:

> On Fri, 07 Feb 2014 18:30:46 +0100, Matthias Beyer said:
>
> > So you would say, I should start patching non-hardware driver code,
> > FS for example, to get my feet wet with the kernel?
>
> You might want to take a step back, be a bit more meta, and ask
> yourself why, exactly, you want to do kernel hacking at all.  If
> there isn't an obvious part of the kernel that interests you, maybe
> kernel hacking isn't where you should be.

  i get asked the same thing on a regular basis, and i've learned to
respond, "have you already downloaded the source, pawed through it,
configured it, compiled it and rebooted it? if not, that's where you
start." no point talking about *hacking* the kernel until you've
worked through the basics of just building and booting one.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

How to test my patches before submitting them to LKML?

[Arlie Stephens]

On Feb 07 2014, Valdis.Kletnieks at vt.edu wrote:
> 
> On Fri, 07 Feb 2014 18:30:46 +0100, Matthias Beyer said:
> 
> > So you would say, I should start patching non-hardware driver code,
> > FS for example, to get my feet wet with the kernel?
> 
> You might want to take a step back, be a bit more meta, and ask yourself
> why, exactly, you want to do kernel hacking at all.  If there isn't an
> obvious part of the kernel that interests you, maybe kernel hacking isn't
> where you should be.

Personally, I'm annoyed by coding cruft. If I thought I could upstream
clean up changes successfully, I'd make a lot of them ;-)  It was
probably a good thing to warn the OP that upstreaming such changes is
going to be extremely difficult. But _making_ and _testing_ that kind
of changes is as good a way to get one's hands dirty as any, and
better than some. 

And IMO, getting one's hands dirty - preferably with more than just
trivial changes or isolated add-ons - is the best way to really
learn. Yes, you need to walk before you can run. And (eventually)
getting feedback will teach you things you might not have learned any
other way. But making changes, testing them, and *not* upstreaming
most of them, can teach you a lot. 

Personally, I have 2 goals:
- get paid 
- get good enough at linux to successfully play in the core kernel 
  (successful == get changes accepted routinely, etc. etc.) 

Doing the former mostly just requires finding the right upstream patch
to apply to our product's elderly kernel, and/or explaining to
developers why their design choices are creating performance issues. 

But even getting good at that limited goal is enhanced by simply
mucking around, writing things that may well duplicate existing
functionality, making big design changes beyond my present skill
level, and generally getting close and personal with the source
code. I wish I had more time to do that, rather than chasing down
(e.g.) the latest thing in creative misuse of the hugetlbfs ;-) 

Of course when I start upstreaming stuff, it'll probably be obvious
fixes for trivial bugs, and/or hardware enablement. I know my skill
and reputation level ;-)  

And the less I get time to just mess around with code, the less likely
I'll achieve the second goal. Given that I'm not doing much on my own
time, I'd say I'm not all that dedicated to it ;-(

--
Arlie

(Arlie Stephens					arlie at worldash.org)

How to test my patches before submitting them to LKML?

[Valdis.Kletnieks at vt.edu]

On Fri, 07 Feb 2014 12:51:42 -0800, Arlie Stephens said:

> Personally, I have 2 goals:
> - get paid
> - get good enough at linux to successfully play in the core kernel
>   (successful == get changes accepted routinely, etc. etc.)
>
> Doing the former mostly just requires finding the right upstream patch
> to apply to our product's elderly kernel, and/or explaining to
> developers why their design choices are creating performance issues.

Which actually kind of makes my point - you have a product, you have
an elderly kernel to support, and that in itself guides you to which
parts of the kernel you need to be paying attention to....
-------------- 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/75cc22ff/attachment.bin