Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels

[Anthony Liguori <anthony@codemonkey.ws>]

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@mit.edu>  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