On Mon, Nov 07, 2011 at 01:08:50PM +0100, Gerd Hoffmann wrote: > > perf *is* an exception today. > > It might make sense to change that. But IMHO it only makes sense if > there is a really broad agreement on it and other core stuff moves into > the kernel too. Then you'll be able to get advantages out of it. For > example standardizing the process to create an initramfs (using the > userspace tools shipped with the kernel) instead of having each distro > creating its own way. I wish distributions had standardized on a single initramfs, sure. But that doesn't mean that the only way to do this is to merge userspace code into the kernel source tree. Everybody uses fsck, originally from the e2fsprogs source tree, and now from util-linux-ng, and that isn't merged into the kernel sources. And I think would be actively *harmful* to merge util-linux-ng into the kernel sources. For a variety of reasons, you may want to upgrade util-linux-ng, and not the kernel, or the kernel, and not util-linux-ng. If you package the two sources together, it becomes unclear what versions of the kernel will work with which versions of util-linux-ng, and vice versa. Suppose you need to fix a security bug in some program that lives in util-linux-ng. If it was bundled inside the kernel, a distribution would now have to release a kernel source package. Does that mean that it will have to ship the a new set of kernel binaries? Or does the distribution have to ship multiple binary packages that derive from the differently versioned source packages? And the same problems will exist with kvm-tool. What if you need to release a new version of kvm-tool? Does that mean that you have to release a new set of kernel binaries? It's a mess, and there's a reason why we don't have glibc, e2fsprogs, xfsprogs, util-linux-ng, etc., all packaged into the kernel sources. Because it's a stupid, idiotic thing to do. - 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
