* Anca Emanuel <anca.emanuel@xxxxxxxxx> wrote: > "I'd even argue that that C library is obviously something the > kernelshould offer as well - so klibc is the way to go and would > help usfurther streamline this and keep Linux quality high." > > I think there is code to share. Why not ? The biggest downside of libc integration into the kernel would be that the libc ABI is *vastly* larger than the kernel ABI, and i'm not sure the kernel community is good enough to handle that. It's roughly 3000 ABI components compared to the 300 ABI functions the kernel has today - so at least an order of magnitude larger... The biggest upside of libc integration into the kernel would be that we could push Linux kernel improvements into the C library - and thus to apps - immediately, along a much larger ABI surface. The 'specialization' resolution of the libc ABI is an order of magnitude larger than that of the kernel's, giving many more opportunities for good, workload specific optimizations and unique solutions. Today the latency of getting a kernel improvement to applications via a change in the C library is above a year, so most kernel people don't actually try to improve the C library but try to find improvements on the kernel level which gets to a distro within a couple of months. If the kernel offers a /proc/libc.so.6 library then the kernel will always be 'in sync' with the library (there's no library to install on-disk - it would be offered by the kernel) and we could use integration techniques like the vDSO uses today. Thanks, 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
