> What is the smartest way to update an old patch set to work with a > current kernel version? in my experience (and I've quite a bit of this:) it's essential to do small steps. There are 2 types of small steps 1) small steps in your patch 2) small steps in what you move it to Both are very important. It helps tremendously if your "feature" is actually a set of relatively small, incremental patches that each do one logical thing at a time. This allows you to do the same *logical* operation for each of the small steps to a new codebase, even if the actual code looks nothing like the original. If you have one big spaghetti of intertwined logical things this isn't possible, but if you have a "1 thing at a time" series you at least have a chance. Another thing is to rebase your patch frequently. It sucks to have to go from 2.6.9 to 2.6.19. A LOT of things have changed. While if you would have gone from 2.6.19 to 2.6.10, then to .11 etc.. the changes would have been a lot smaller, easier to track down and easier to adjust to. Even now that you are where you are, I'd suggest going via at least one, if not two, intermediate steps. Say 2.6.12 and 2.6.15. Make those work first, test them a lot, and only then go to the next step. (and going forward, once you are at a current tree, keep up with mainline *frequently*) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
