Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/18/2010 11:13 AM, Ingo Molnar wrote:
> Good that you mention it, i think it's an excellent example.
> The suckage of kernel async IO is for similar reasons: there's an ugly package
> separation problem between the kernel and between glibc - and between the apps
> that would make use of it.
>
> ( With the separated libaio it was made worse: there were 3 libraries to
>    work with, and even less applications that could make use of it ... )
>
> So IMO klibc is an arguably good idea - eventually hpa will get around posting
> it for upstream merging again. Then we could offer both new libraries much
> faster, and could offer things like comprehensive AIO used pervasively within
> existing APIs.
>    

And why wouldn't the kernel developers produce posix-aio within klibc.

posix-aio is also a really terrible interface (although not as bad as 
linux-aio).

The reason boils down to the fact that these interfaces are designed 
without interacting with the consumers.  Part of the reason for that is 
the attitude of the community.

You approached this discussion with, "QEMU/KVM sucks, you should move 
into the kernel because we're awesome and we'd fix everything in a heart 
beat".  That attitude does not result in any useful collaboration.

Had you started trying to understand what the problems that we face are 
and whether there's anything that can be done in the kernel to improve 
it, it would have been an entirely different discussion.

The sad thing is, QEMU is probably one of the most demanding free 
software applications out there today with respect to performance.  We 
consume interfaces IO interfaces and things like large pages in a deeper 
way than just about any application out there.

We've been trying for a long time to improve Linux interfaces for years 
but we've not had many people in the kernel community be receptive.

We've failed to improve the userspace networking interfaces.  Compare 
Rusty's posting of vringfd to vhost-net.  They are the same interface 
except we tried to do something more generally useful with vringfd and 
it was shot down because it was "yet another kernel/userspace data 
transfer interface".  Unfortunately, we're learning that if we claim 
something is virtualization specific, we avoid a lot of the kernel 
bureaucracy.  My concern is that over time, we'll have more things like 
vhost and that's bad for everyone.

Regards,

Anthony Liguori