How to test my patches before submitting them to LKML?
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.
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...
On 07-02-2014 11:10:59, Valdis.Kletnieks@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.
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.
On Fri, 7 Feb 2014, Valdis.Kletnieks@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 ========================================================================
On Feb 07 2014, Valdis.Kletnieks@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@worldash.org)
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....
participants (4)
-
Arlie Stephens -
Matthias Beyer -
Robert P. J. Day -
Valdis.Kletnieks＠vt.edu