Re: [klibc] klibc and what's the next step?

[Greg KH <greg@kroah.com>]

On Tue, Jun 27, 2006 at 09:39:30AM -0400, Jeff Garzik wrote:
> 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.

I second this statement, having a method of implementing early boot
userspace options is a very good thing to have, and one that the distros
really want (as they have already been doing it on their own in
different ways, some using klibc already, others using uclibc, and still
others using glibc.)  Standardizing on a method to implement this is
very much needed.

thanks,

greg k-h
-
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/