[klibc] Merge strategy for klibc
H. Peter Anvin
hpa at zytor.com
Mon Mar 20 11:54:01 PST 2006
Okay, as of this point, I think klibc is in quite good shape; my
testing so far is showing that it can be used as a drop-in replacement
for the kernel root-mounting code.
That being said, there is guaranteed to be breakage, for two reasons:
a. There are several architectures which don't have klibc ports yet.
Since I don't have access to them, I can't really do them, either.
It's usually a matter of an afternoon or less to port klibc to a
new architecture, though, if you have a working development
environment for it.
b. There are a gajillion options in the way Linux handles its root
filesystem. I have tried to implement them all, but I haven't been
able to test some of the more exotic conditions, mostly due to the
fact that every boot environment I set up takes a *lot* of time and
maintenance. This has in fact been the by far the bulk of the time
I've spent on klibc, not writing code.
Thus, it's not clear to me what particular approach makes most sense for
1. Mechanism: the easiest for me would of course be git pull, but I'm
certainly willing to break it up into patches or any other useful way.
A diff of by git tree from 2.6.16 gives:
766 files changed, 84024 insertions(+), 3059 deletions(-)
2. State: the current git tree cleans up the arch-specific code for i386
and x86-64; other architectures are going to need some minor cleanup in
setup.c or the equvalent.
The current git tree includes a number of utilities, like dash (sh),
which aren't used by the default kinit configuration. Additionally,
right now kinit is built monolitically, in other words there isn't a
CONFIG_ option to turn off nfsmount, for example.
Again, I'm more than willing to put the tree in any particular state
that makes sense.
3. Path: it probably would make sense to push this into -mm first?
It's taken this long, I'd like to make this actually happen...
More information about the klibc