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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ open-vm-tools-devel mailing list open-vm-tools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
