Re: klibc - another libc?

Roman Zippel
2006-06-10T23:38:09Z

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