On Mon, Dec 18, 2006 at 11:47:38AM -0500, Bj?rn wrote:
> I kind of inherited some kernel code that I need to take care of now.
> The code has been developed on Linux 2.6.9 and I would like to move it
> to a current kernel version. The code itself is not meant for
> production or merge and is quite intrusive (it's a scheduler). What
> makes the whole thing even worse is that it was developed on the RHEL
> 4 kernel. I came up with the following ideas:
>
> 1) Diff RHEL 4 vs modified, try to apply patch and clean up conflicts
> pro: should not pick up any RHEL patches
> contra: there will probably many conflicts, as the scheduler has
> apparently change a lot
>
> 2) Diff RHEL 4 vs modified, try to clean up patch manually and remove
> any section that is likely to cause trouble (= scheduler hooks) and
> re-implement those by hand
> pro: less conflicts (hopefully)
> contra: more manual work, and I don't have the experience to
> anticipate likely conflicts
>
> 3) create many diffs off directories and/or files and try to apply
> those smaller patches
> pro: easier to keep an overview
> contra: more work, doesn't really change anything about conflicts
Or 4) :
4) figure out how your scheduler works and put it into plugsched.
pro: uses an established framework
pro: probably less work for future kernels, especially if you push your
patch upstream
contra: needs work figuring out how your scheduler works
See http://lwn.net/Articles/212183/ .
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
