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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux