* Anca Emanuel <anca.eman...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
