On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote: > > I'm sure perf developers break the ABI sometimes - that happens > elsewhere in the kernel as well. However, Ted claimed that perf > developers use tools/perf as an excuse to break the ABI _on purpose_ > which is something I have hard time believing. I remember an assertion, probably a year or two ago, probably at the previous year's kernel summit, that one of the reasons for having the perf code inline in the kernel was so that synchronized changes could be made to both the kernel and userspace tool together. So it's not a matter of breaking the ABI _on_ _purpose_, it's an assertion that there is no ABI at all. Since the perf tool and the kernel tool have to be built together, so long as a user does that, no harm, no foul. Recall that Linus has said that he doesn't care about whether or not something is an ABI; he only care if users code don't perceive breakage. If they didn't perceive breakage, then it doesn't matter if an interface is changed. So the real question is whether or not this was an excuse to break the ABI, but whether or not the perf developers acknowledge there is an ABI at all, and whether it's OK for other developers to depend on the syscall interface or not. Actually, though, it shouldn't matter, because intentions don't matter. Recall the powertop/ftrace case. If you expose an interface, and people start using that interface, then you can't break them, period. So as far as Vince is concerned, if you have a userspace library which depends on the perf interface, then you should try out the kernel after each merge window, and if your library breaks, you should complain to Ingo and Linus directly, and request that the commit which broke your tool to be reverted --- because that's the rule; no breakage is allowed. As far as kvm-tool being in the kernel, I still don't see particularly valid arguments for why it should be in the kernel. It can't be the perf argument of "we can make simultaneous changes in the userspace and kernel code", because if those changes break qemu-kvm, then a complaint to Linus will cause the problem code to be reverted. As far as the code using the same coding conventions and naming conventions as the kernel, that to me isn't a particular strong argument either. E2fsprogs uses the Signed-off-by lines, and the same coding conventions of the kernel, and it even has a slightly modified version of two kernel source file in e2fsprogs (e2fsck/recovery.c and e2fsck/revoke.c), plus a header file with data structures that have to be kept in sync with the kernel header file. But that doesn't make it "part of the kernel", and it's not a justification for it to be bundled with the kernel. Personally, I consider code that runs in userspace as a pretty bright line, as being "not kernel code", and while perhaps things like initramfs and the crazy ideas people have had in the past of moving stuff out of kernel/init.c into userspace might have qualified as stuff really close to the kernel, something like kvm-tool that runs way after boot, doesn't even come close. Wine is another example of another package that has lots of close kernel ties, but was also not bundled into the kernel. The precedent has all mainly been on the "keep the kernel separate" side of things, and the arguments for bundling it with the kernel are much weaker, especially since the interface is well-developed, and there are external users of the interface which means you can't make changes to the interface willy-nilly. Indeed, when the perf interface was changing all the time, maybe there was some convenience to have it be bundled with the kernel, so there was no need to negotiate interface version numbers, et. al. But given how it has to link in so many user space libraries, I personally think it's fair to ask the question whether now that it has matured, whether it's time to move it out of the kernel source tree. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
