Re: klibc and what's the next step?

Roman Zippel
2006-06-28T23:57:17Z

Hi,

On Tue, 27 Jun 2006, Milton Miller wrote:

> > I could now repeat all the concerns I already mentioned, why it
> > shouldn't
> > be merged as is (that doesn't mean it shouldn't be merged at all!), but
> > they have been pretty much ignored anyway...
>
> I'm guessing these threads?
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114946240404001&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114967046318388&w=2

Yes.

> Let me see if I can summarize:
>
> * There is concern about how much is bloat, where do we draw the line
> for in-kernel

That actually wouldn't be my initial concern. Otherwise I'm happy to point
out kernel bloat, but here it's more important to prototype a mechanism.
In this case bloat can still be fixed later, as it's rather isolated
behind a standard API.

> * There is concern about duplicating user space utilities. We moved
> the kernel broken md assemble instead of getting the current one from
> mdadm, and that should be part of mdadm package.

The problem here is twofold. First, duplication means extra maintenance
overhead, various version of the copies have to be kept in sync. The
temptation to fix only the kernel version without updating the normal
version could be quite big, so that users might not realize they have
broken tools until they e.g. try reconfigure the system.
Second, whatever we deliver with the kernel, might become part of kernel
API (e.g. config files), which needs to be supported for a long time.
Compatibility code can accumulate rather quickly.

> * Some distributions are already using klibc and have been. They see
> the reason to merge is to have the canonical api with the kernel to
> avoid version mismatch.

klibc will continue as independent project anyway, so it should not be
difficult to include from the kernel whatever the distribution provides.
It would help avoiding possible problems with mixing binaries built from
different libraries.

bye, Roman