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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
