The True Meaning of EXPORT_SYMBOLS_GPL

Richard Yao asked why the LZ4 code, which was clearly under a BSD license, had its symbols included in the EXPORT_SYMBOLS_GPL code.

Matthew Garrett replied, "EXPORT_SYMBOL_GPL is intended [as] an indication that using a symbol is likely to result in you producing a derived work of the kernel, and the kernel as a whole is under the GPL. It has nothing to do with additional licenses that individual pieces of code may be available under."

Joe Perches gave a link to an interesting summary of the debate over this issue [1]. Rob Landley thought that the whole discussion was legally dangerous. He said that EXPORT_SYMBOLS_GPL was intended to indicate when the use of kernel source code constituted a derived work (and thus when any distribution of that work would need to be licensed under the GPL). He didn't want to give the anti-GPL lawyers any ammunition to claim that anything other than that might be the case.

Joe, however, replied that Matthew's "declarative statement that EXPORT_SYMBOL_GPL is 'intended [as] an indication that using [the] symbol is likely to result … .' is incomplete. There are competing histories as to what EXPORT_SYMBOL_GPL was intended to do."

Matthew replied that the history and meaning of EXPORT_SYMBOLS_GPL wasn't really in doubt. And there, this time, the discussion ended.

Atomic Renames

Miklos Szeredi posted a patch to add a new system call, rename2(), to go alongside the rename() system call. The rename() call changes the name of a file. The rename2() call takes two files and swaps their names, so the first ends up with the name of the second, and the second ends up with the name of the first. Eventually, Miklos would like to see the behavior of rename2() folded into that of rename(), but he didn't want to do that at the start because it would make the patch balloon up in size.

About his patch, he said: "This allows interesting things, which were not possible before, for example atomically replacing a directory tree with a symlink."

He added, "The other reason to introduce this is for whiteout handling in union/overlay solutions in an atomic manner without having to add complex code to each filesystem's rmdir, mkdir and rename just for handling whiteouts." A whiteout is when you have a union filesystem and want to delete a file that resides on a read-only filesystem. When you delete the file under those circumstances, the union filesystem uses a whiteout to make it look to the user as though the file has really been deleted.

He pointed out that, although most whiteout cases would be solved with rename2(), there were still cases that wouldn't, and he mentioned that a new flag would be needed eventually to handle those remaining cases.

H. Peter Anvin suggested that instead of a simple A-to-B and B-to-A name exchange, Miklos should use a more complicated rename3() solution that would rename A to B, but then if B already existed it would rename B to C. Peter pointed out that this would encompass Miklos's original behavior, because rename(C,B,C) would accomplish the same file swap Miklos had envisioned.

Linus Torvalds stepped in at that point, saying that, actually, Miklos had already implemented that three-name version, but that it had been much more complicated and didn't fit as well with the rest of the API. Miklos's rename2() was actually the simpler and more preferable revision, Linus said. He added, "I was actually very relieved to see this much simpler and cleaner model, because the alternative really was nasty. This one looks fairly simple and clean and straightforward."

Andy Lutomirski suggested adding a flag to the new system call that would prevent a rename if the destination filename already existed on the filesystem. Linus agreed that this would be good, and the thread ended there.

Speeding Up AMD Kernels

Austin Hemmelgarn posted a patch to optimize a bunch of AMD CPUs. He said, "These provide noticeable improvements over the K8 config option, and allow the kernel to take full advantage of AMD specific instruction set extensions, such as ABM, LZCNT, and POPCNT."

Borislav Petkov replied that "A patch like that keeps popping up every couple of months. Please show us those noticeable improvements because the guy last time failed to do so." Borislav added that distribution kernels always shipped with only generic CPU support, so Austin's patch, at best, would help a very small subset of users who downloaded and compiled their own kernels.

Austin asked why it was so important to show measurable speedup, if the worst-case scenario was that almost no one would use the configuration option. However, he agreed to run the tests. Borislav replied, "Just having the option for no good reason at all is a no-no." A couple of posts later, he added, "If it doesn't bring any performance improvement – and I don't want to rain on your parade but I think it won't, at least not enough to warrant a serious look – there's absolutely no reason to add it."

Austin ran a few tests using his PILEDRIVER config option and reported that "build jobs appear to be much improved. Building kernel 3.12-rc2 with allmodconfig using 8 jobs on a FX-8320 takes 22 minutes and 57 seconds on a kernel with CONFIG_MK8, 21 minutes and 35 seconds on a kernel with CONFIG_GENERIC, and 19 minutes and 11 seconds on a kernel with CONFIG_PILEDRIVER. I see similar results for a build of GCC 4.7 (45m1s, 41m39s, and 38m56s)."

He added, "I don't know about you, but that sure seems to be a worthwhile performance increase to me." Linus Torvalds replied, "That's certainly noticeable. Surprisingly so."

Linus asked if Austin had run any kernel profiling, to see exactly where the speedup occurred. Borislav also ran his own tests using Austin's PILEDRIVER option. He reported, "I don't really see any of those improvements above. Actually, -march=bdver2 is even slightly worse in comparison to mk8. And the workload is of building a config specific to that machine but allmodconfig looks very similar, the numbers being simply higher."

Austin remarked, "Part of the difference between our results may be that I have my entire userspace built with -mtune=bdver2, so less of the time is spent in userspace." He added, "With regards to the differences shown above relative to CONFIG_MK8, that does actually make sense; with CONFIG_MK8, gcc makes very minimal use of extension instructions (afaik, only MMX, SSE, and 3Dnow!), this improves performance slightly on bulldozer derivatives because there are only half as many SSE and FP units as CPU cores."

Borislav replied, "That still cannot explain the huge difference between building on a mk8 vs bdver2 kernel. Provided your userspace is the same and only the kernels are different, I don't see how that happens."

The discussion ended around there with no conclusive performance improvement shown for Austin's patch, and no conclusive disproof either. To get into the kernel, however, proof of value would be the deciding factor.