Re: klibc and what's the next step?

[Jeff Garzik <jeff@garzik.org>]

Roman Zippel wrote:
> What I'm more interested in is basically answering the question and where 
> I hope to provoke a bit broader discussion: "What's next?"
>
> Until recently for most developers klibc was not much more than a cool 
> idea, but now we have the first incarnation and now we have to do a 
> reality check of how it solves our problems. To say it drastically the 
> current patch set as it is does not solve a single real problem yet, it 
> only moves them from the kernel to kinit, which may be the first step but 
> where to?
>
> So what problems are we going to solve now and how? The amount of 
> discussion so far is not exactly encouraging. If nobody cares, then there 
> don't seem to be any real problems, so why should it be merged at all? Are 
> shiny new features more important than functionality?

Well, at least for me...  at boot time we run into various limitations 
from the current kernel approach of coding purely userspace activities 
in the kernel, simply because a vehicle for implementing early-boot 
userland operations did not exist.

This klibc patchkit removes stuff that does not need to be in the 
kernel, and provides a platform for improving IP autoconfig, NFS root, 
MD/DM root setup, and various other early-boot activities.

A lot of the larger distros have been moving in this direction anyway, 
by necessity.  They have been stuffing more and more [needed] logic into 
initrd [which is often really initramfs these days], to deal with 
complex boot and root-mounting scenarios like iSCSI and multi-path.

	Jeff


-
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/