On 11/07/2011 03:36 PM, Pekka Enberg wrote:
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o<tytso@xxxxxxx> wrote:
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.
It's not as clear line as you make it out to be.
KVM tool also has mini-BIOS code that runs in guest space. It has a
code that runs in userspace but is effectively a simple bootloader. So
it definitely doesn't fit the simple definition of "running way after
boot" (we're _booting_ the kernel too).
Linsched fits your definition but is clearly worth integrating to the
kernel tree. While you are suggesting that maybe we should move Perf
out of the tree now that it's mature, I'm pretty sure you'd agree that
it probably would not have happened if the userspace parts were
developed out of tree.
There's also spectacular failures in the kernel history where the
userspace split was enforced. For example, userspace suspend didn't
turn out the way people envisioned it at the time. We don't know how
it would have worked out if the userspace components would have been
in the tree but it certainly would have solved many if the early ABI
issues.
I guess I'm trying to argue here that there's a middle ground. I'm
willing to bet projects like klibc and unified initramfs will
eventually make it to the kernel tree because they simply make so much
sense. I'm also willing to be that the costs of moving Perf out of the
tree are simply too high to make it worthwhile.
Does that mean KVM tool should get a free pass in merging? Absolutely
not. But I do think your position is too extreme and ignores the
benefits of developing userspace tools in the kernel ecosystem which
was summed up by Anthony rather well in this thread:
https://lkml.org/lkml/2011/11/7/169
The kernel ecosystem does not have to be limited to linux.git. There could be a
process to be a "kernel.org project" for projects that fit a certain set of
criteria. These projects could all share the Linux kernel release cadence and
have a kernel maintainer as a sponsor or something like that.
That is something that could potentially benefit things like e2fs-tools and all
of the other tools that are tied closely to the kernel.
In fact, having a single place where users could find all of the various kernel
related tools and helpers would probably be extremely useful. There's no reason
this needs to be linux.git though, this could just be a web page on kernel.org.
Regards,
Anthony Liguori
Pekka
--
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
