Re: klibc and what's the next step?

[Roman Zippel <zippel@linux-m68k.org>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/