Re: Enhance perf to support KVM

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

 



* Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:

> On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
> >You imply lockstep updates because both are on the same source tree? I
> >don't see why that would be required, there is an ABI contract to be
> >respected no matter where the sources for the signatories live.
> 
> It's not about ABIs, it's about not being able to rely exclusively on new 
> syscalls or flags (one for all: SOCK_NONBLOCK) because people can run new 
> glibc on old kernels.

That is not what i was suggesting though.

I am suggesting a klibc-alike approach, where glibc is not on the filesystem 
but mapped by the kernel, basically as an extension of the standard vDSO.

We always have most of glibc paged in all the time, so there's no real RAM 
usage difference.  (and ultra-embedded would sure make use of this to trim RAM 
usage in fact.)

That way the C library comes with the kernel. New kernel, new/updated system 
library.

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