Software Freedom Conservancy

Contribution and Similarity Analysis of Christoph Hellwig's Linux Code as found in VMware ESXi 5.5

This analysis verifies by reproducible analysis a set of specific contributions that are clearly made by Christoph Hellwig to Linux, and shows how those contributions appear in the VMware ESXi 5.5 product.

This analysis was prepared and written by Bradley M. Kuhn.

Understanding Code Similarity and "Cloning"

Software is often modified in various ways; indeed, Linux developers form a community that encourages and enables modification by many parties. Given this development model, communities often find it valuable to determine when software source code moves from one place to another with only minor modifications. Various scientifically-vetted techniques can be used to identify "clones" -- a portion of code that is substantially similar to pre-existing source code. The specific area of academic research is called "code cloning detection" or "code duplication detection". The area has been under active research since the mid-1990s 1. In 2002, Japanese researchers published a tool called CCFinder 2, which, in its updated incarnation (called CCFinderX), is widely used and referenced by academic researchers in the field 3 and has specifically been used to explore reuses of code in GPL'd software such as Linux 4.

CCFinderX uses a token-based clone detection method and a suffix-tree matching algorithm; both techniques have been highly vetted and considered in the academic literature. The techniques are considered viable and useful in detecting clones. Many academic papers on the subject have been peer-reviewed and published, and nearly every newly published paper compares its new techniques of clone detection to the seminal results found by CCFinderX. For purposes of our analysis, we have therefore chosen to use CCFinderX. These results can be easily reproduced since CCFinderX is, itself, also Open Source software.

Establishing A Baseline of the CCFinderX Tool

CCFinderX offers many statistics for clone detection. After expert analysis, we concluded that most relevant to this situation is the "ratio of similarity" between the existing code and the new code. To establish a baseline, we considered two different comparisons of Free and Open Source Software (FOSS). First, we compared the Linux kernel, Version 4.5.2, to the FreeBSD kernel, Version 10.3.0. This comparison was inspired by the similar 2002 study 5 of these two large C programs. The hypothesis remained that CCFinderX would encounter a low but significant percentage of code similarity, since the FreeBSD and Linux projects collaborate on some subprojects and willingly share code under the 3-Clause BSD license for those parts. (These collaborations are public and well-documented.)

The experiment confirmed the hypothesis. We found that a 3.68% "ratio of similarity" when comparing code from Linux to the FreeBSD kernel.

Next, we compared the source code of the Linux Kernel 4.5.2 to the LLVM+Clang system, version 3.8.0. These two projects are each a large program that are not known to actively share code. There may be some very minimal similarity simply due to chance, but something much lower than the 3.68% found between Linux and FreeBSD's kernel.

Indeed, when the same test is run to compare Linux to the LLVM+Clang system, the "ratio of similarity" was 0.075%.

General Comparison of Linux Kernel to VMware sources

With the baseline established, we now begin relevant comparisons. First, we compare the Linux kernel version 2.6.34 to the sources released by VMware in their (partial) source release. The "ratio of similarity" between Linux 2.6.34 and VMware's partial source release is 20.72%. There is little question that much of VMware's kernel has come from Linux.

Methodology Of Showing Hellwig's Contributions in VMware ESXi 5.5 Sources

The following describes a methodology to show Hellwig's contributions to Linux, and how they compare to code found in VMware ESXi 5.5.

Extracting Hellwig's Contributions From Linux Historical Repository

Excellent records exist of contributions made to Linux from 2002-02-04 through present date. From 2002-02-04 through 2005-04-03, Bitkeeper was used to store revision control history of Linux. Each improvement contributed to Linux has information regarding who placed the contribution in Linux, and a comment field in which the contributor can credit others, such as by noting that the contribution actually came from someone else.

I extracted from the historical Linux tree the identifying number of all commits that are either made with Hellwig in the official Author field, or where the person in the Author field left notes clearly indicating that the contribution was done by Hellwig. For the latter, the following regular expression search against the log file was used:

(Submitted\s+by|original\s+patch|patch\s+(from|by)|originally\s+(from|by)).*Hellwig

Specifically, I used a script to extract a list of commit ids from the historical Linux repository. This method found 1,012 separate occasions of contribution by Hellwig from 2002-02-04 through 2005-04-03.

After finding these separate occasions of contribution, I then extracted the source code lines that Hellwig added or changed in each contribution in this repository. I did so by carefully cross-referencing the commits that Hellwig performed with the output of git blame. I specifically wrote a script to carefully extracted only lines that Hellwig changed or added in that repository, and placed only those contributions identifiable as Hellwig's into new files whose named matched the original filenames. This created a corpus of code that can be verifiable as added or changed by Hellwig and no one else.

Here are the specific commands I ran:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git linux-historical
$ ./commit-id-list-matching-regex.plx `pwd`/linux-historical/.git Hellwig '(Submitted\s+by|originals+patch|patch\s+from|originally\s+by).*' > hellwig-historical.ids
$ ./extract-code-added-in-commits.plx --repository=`pwd`/linux-historical --output-dir=`pwd`/hellwig-historical --central-commit e7e173af42dbf37b1d946f9ee00219cb3b2bea6a --progress --blame-opts=-M --blame-opts=-C < ./hellwig-historical.ids
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-current
$ ./commit-id-list-matching-regex.plx `pwd`/linux-current/.git Hellwig '(Submitted\s+by|original\s+patch|patch\s+(from|by)|originally\s+(from|by)).*' > ./hellwig-current.ids
$ ./extract-code-added-in-commits.plx --progress --repository=`pwd`/linux-current --output-dir=`pwd`/hellwig-through-2.6.34 --fork-limit=14 --blame-opts=-M  --blame-opts=-M --blame-opts=-C --blame-opts=-C --central-commit e40152ee1e1c7a63f4777791863215e3faa37a86   < hellwig-current.ids 

Note: e40152ee1e1c7a63f4777791863215e3faa37a86 is the 2.6.34 version created by Linus Torvalds on 2010-05-16 14:17:36 -0700, with Git commit comment: "Linus 2.6.34".

Comparing Hellwig's Contributions From Linux Historical Repository to VMware Sources

I then used this corpus as input to CCFinderX (similar to the other CCFinderX comparisons explained earlier). Specifically, this CCFinderX comparison compared all known Hellwig-contributed material from the historical Linux repository to the partial VMware source release. CCFinderX found a ratio of similarity of 0.0900% between Hellwig's code and the source code in VMware's (partial) source release. CCFinderX specifically identified 12 distinct locations where substantial sections of code contributed by Hellwig appeared in VMware's code.

Most notably, substantial portions of the the following core SCSI functions were found by this search technique: __scsi_device_lookup and __scsi_get_command, mpt_get_product_name, scsi_proc_host_rm, mega_enum_raid_scsi, mega_m_to_n, mega_prepare_passthru, proc_scsi_show, and __down_read_trylock.

Extracting Hellwig's Contributions From Modern Linux Repository

Beginning on 2005-04-16, Linux began using the new Git system to store revision history. This history can be analyzed in a similar fashion as was done for the historical repository.

In this case, I picked a specific revision to center the analysis, the Linux 2.6.34 release from 2010-05-16. For the period from 2005-04-16 through 2010-05-16, I extracted from the modern Linux tree the identifying number of all commits that are either made with Hellwig in the official Author field, or where the person in the Author field left notes clearly indicating that the contribution was done by Hellwig. For the latter, the following regular expression search against the log file was used (as before):

(Submitted\s+by|original\s+patch|patch\s+(from|by)|originally\s+(from|by)).*Hellwig

Specifically, I used the same script as before to now extract a list of commit ids from the modern Linux repository. This method found 2,595 separate occasions of contribution by Hellwig from 2005-04-16 through 2010-05-16.

As before, after finding these separate occasions of contribution, I then extracted the source code lines that Hellwig added or changed in each contribution in this repository. I did so by carefully cross-referencing the commits that Hellwig performed with the output of git blame. I specifically used the same script as before to carefully extracted only lines that Hellwig changed or added in that repository, and placed only those contributions identifiable as Hellwig's into new files whose named matched the original filenames. This created a corpus of code that can be verifiable as added or changed by Hellwig and no one else.

Comparing Hellwig's Contributions From Modern Linux Repository to VMware Sources

I then used this corpus as input to CCFinderX again. Specifically, this CCFinderX comparison compared all known Hellwig-contributed material from the modern Linux repository to the partial VMware source release. CCFinderX found a ratio of similarity of 0.1615% between Hellwig's code and the source code in VMware's (partial) source release was contributed by Hellwig. CCFinderX specifically identified 23 distinct locations where substantial sections of code contributed by Hellwig appeared. These 23 locations are found in the following 19 functions: mptsas_init, mptsas_get_linkerrors, megasas_build_and_issue_cmd, cciss_getgeo, mptsas_get_bay_identifier, phy_to_ioc, mptsas_sas_enclosure_pg0, SendIocInit, mptsas_parse_device_info, csmisas_sas_device_pg0, mptsas_sas_io_unit_pg0, mptsas_sas_io_unit_pg1, mptsas_sas_expander_pg1, mptsas_sas_enclosure_pg0, aac_handle_aif, mptsas_get_bay_identifier, mpt_host_page_alloc, mptsas_probe_one_phy.

Changed And Added Lines Create an Incomplete Picture

In Estimating the Total Cost of a Linux Distribution, McPherson, Proffitt, and Hale-Evans write:

Anyone who is familiar with kernel development, for instance, realizes that the highest man-power cost in its development is when code is deleted and modified. The amount of effort that goes into deleting and changing code, not just adding to it, is not reflected in the values associated with this estimate. Because in a collaborative development model, code is developed and then changed and deleted, the true value is far greater than the existing code base. Just think about the process: when a few lines of code are added to the kernel, for instance, many more have to be modified to be compatible with that change. The work that goes into understanding the dependencies and outcomes and then changing that code is not well represented in this study.

Therefore, the process described herein, which ignores lines that are deleted (thus streamlining and improving code), also ignores a fundamental tenant of software development. Namely, making code smaller, more expressive, and more concise yields better-designed and more easily maintainable software. While the process herein can produce a clear list of code whose known introduction is directly attributable to Hellwig, the analysis produced by this process does not do justice to the full weight of the contributions made by Hellwig, since removed code is outright ignored in this process.

However, we can consider this process above to have found a bare minimum of Hellwig's contributions that appear in VMware's partial source release.

Further Analysis of Additional Examples

Separately from the analysis above, Hellwig identified a specific list of eight critical C functions to which he specifically recalls contributing, and near-equivalents were found in VMware's ESXi 5.5 product.

In this additional analysis, we used CCFinderX in a different way 6. In these tests, I confine the code tests to specific small sections of code that were previously identified by human analysis as similar. In this way, I used CCFinderX to confirm with computational analysis what was already obvious to the human eye.

As expected, the ratio of similarity between the Hellwig's implementation and the corresponding implementation found in VMware's ESXi 5.5 product are quite high. As show in the table below, these particular functions show a incredibly high degree of similarity.

Function Ratio of Similarity
scsi_destroy_command_freelist 82.9545%
__scsi_device_lookup 98.4375%
scsi_device_lookup 58.4785%
__scsi_get_command 69.2308%
__scsi_iterate_devices 47.6190%
scsi_put_command 49.0347%
scsi_remove_single_device 99.0566%
scsi_setup_command_freelist 14.8148%

  1. B. S. Baker. On finding duplication and near-duplication in large software systems. In Second Working Conference on Reverse Engineering, pages 86–95, Los Alamitos, California, 1995.

  2. T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: A multi-linguistic token-based code clone detection system for large scale source code. IEEE Transactions on Software Engi- neering, 28(7):654–670, July 2002.

  3. Online list of citations to CCFinder and CCFinderX

  4. Yu Kashima, Yasuhiro Hayase, Norihiro Yoshida, Yuki Manabe, Katsuro Inoue. An Investigation into the Impact of Software Licenses on Copy-and-paste Reuse among OSS Projects. WCRE 2011: 28-32

  5. T. Kamiya, S. Kusumoto, and K. Inoue. CCFinder: A multi-linguistic token-based code clone detection system for large scale source code. IEEE Transactions on Software Engi- neering, 28(7):654–670, July 2002.

  6. For this analysis, we set the configuration parameters on CCFinderX to a minimum clone length of 15 and minimum TKS of 10. Research papers on CCFinder and its documentation discuss these settings further.

Main Page | Contact | Sponsors | Privacy Policy | RSS Feed

Find Conservancy on pump.io, Twitter, Youtube, Google+ and other social networks too!