RE: [open-vm-tools-devel] Getting the kernel modules into Linux mainline

[Chris M. <ma...@ch...>]

On Tue, 2008-11-18 at 12:57 -0800, Adar Dembo wrote:
> > Just for completeness, here's the updated patch for vmblock, which I've
> > run through the vmblocktest tool that Adar posted.  Seems a shame not to
> > post it somewhere so you guys might as well have it!
> > 
> > It's checkpatch and sparse clean, and applies against 2.6.27.
> 
> Thanks, Chris. When the vmblock-fuse code gets added to the open-vm-tools we can bring this patch out and talk about what happens next.
> 
> Just out of curiosity, how long did this cleanup effort take? We're trying to gauge how much work is involved in preparing a module for inclusion upstream, and since you're the first to try, your feedback would be appreciated.
> 

Probably took me longer than somebody who was already familiar with the
code; I systematically went through each file in turn, doing the easy
stuff like whitespace first and committing after each one, using
checkpatch.pl as a guide to how much work was left to complete (i.e. the
number of lines with warnings / total LOC). I had a script to run
checkpatch, compile with sparse, compare object code and print out a
"percent done" as an incentive! Took about 3 weeks (doing an hour or two
per day) to get to the state of the original patch, where it was clean
of warnings but still looked a bit "alien" wrt other kernel code.

By that time I was familiar enough with the code that I could start with
an empty file and (using similar modules like romfs as a guide) build it
up from the bottom with linux kernel-style identifiers and paste only
the bare minimum code. That was pretty quick, a few days maybe.

Since then I've just had to diff -rup the vmblock directory in the
subsequent open-vm-tools releases to grab the latest relevant stuff
which was pretty straightforward, and probably not a huge amount of
ongoing maintenance effort.

If I was going to do it again, if the source looks like it needs
substantial rework, then there isn't much value in hundreds of
individual commits; I think I'd jump straight into creating the module
from scratch and pasting the relevant code snippets directly.  Some
documentation and test harnesses would be really really useful here,
because then you could be a bit less paranoid about diffing object code
at each stage.

cheers
Chris