Re: klibc - another libc?

[Roman Zippel]

Hi,

On Sat, 10 Jun 2006, Sam Ravnborg wrote:

> > Well for now you pretty much just moved code, that was in the kernel 
> > before. What I'm trying to find out is what is coming next. How does e.g. 
> > udev or modules fit into the picture?
> udev and module-init-tools fits nicely with the kernel. I never have
> understood this 'keep-everyhig-separate' mantra. Just see how many
> people had troubles with missing module-init-tools or people having
> troubles with non-backward compatible udev.

It just means that we suck at producing stable kernel interfaces.
Moving everything into the kernel doesn't magically solve problem, it only 
shifts the problem.
You still had to define the boundaries - how does it interface with the 
rest of the system. This is the part I'm currently trying to figure out 
regarding klibc.

> > For -mm that's fine, but do you seriously expect it to get merged like 
> > that. Again, what makes klibc so special, that it doesn't have to follow 
> > standard rules?
> So part of what you ask for is a set of incremental patches that shows
> all the kernal modifications?

Well, it's common practice. If we start making exceptions, everyone wants 
one, so it IMO would need a very, very good reason to merge this as is.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/