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
pushing upstream.
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...
-hpa
On Mon, 2006-03-20 11:54:01 -0800, H. Peter Anvin <hpa@zytor.com> wrote:> 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.I haven't yet looked at your code, but what actually needs to be done? Defining syscall macros? I'd probably give it a try for VAX. MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O f?r einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.zytor.com/pipermail/klibc/attachments/20060320/40820a79/attachment.bin
On Mon, Mar 20, 2006 at 11:54:01AM -0800, H. Peter Anvin wrote:> 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.Which ones?
Hi, first thanks for your good work on that! On Monday, 20. March 2006 20:54, H. Peter Anvin wrote:> The current git tree includes a number of utilities, like dash (sh), > which aren't used by the default kinit configuration.But its quite useful to be dropped into a shell, if anything goes wrong. e.g. ubuntu assumes an modular kernel, which I don't like to have and I got dropped into the shell quite often until all scripts worked as expected.> Additionally, > right now kinit is built monolitically, in other words there isn't a > CONFIG_ option to turn off nfsmount, for example.Yes, since after development of your init setup, you want to shrink it as much as possible :-) But all of this stuff is janitorial and can be done after merging the basic ideas and completing the setup code move to user space. Another idea is to still allow the current archive setups for initramfs, because a static /dev might be best for embedded stuff where you basically pre-compose a system image and download that to flash.> 3. Path: it probably would make sense to push this into -mm first?The usr/ part should go in ASAP, but please rip out the setup stuff only after a grace period announced in Documentation/feature-removal.txt or sth. like that. Regards Ingo Oeser -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://www.zytor.com/pipermail/klibc/attachments/20060320/4f9c5f58/attachment.bin
Hi, On Mon, 20 Mar 2006, H. Peter Anvin wrote: You forgot to provide any information (at least a summary) about what this is and how this will work. Please don't assume everyone is familiar with it. There is one major question: how will this interface to distributions? How can distributions add their own initializations and configurations or are they going to put an initrd on top of the kernel initrd? If this will have a kernel and a distribution part, it poses the question whether klibc has to be distributed with the kernel at all (a libc has a standard API after all) and the kernel just provides the kernel specific parts to whatever the distribution provides. bye, Roman
H. Peter Anvin wrote:> 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.[]> Thus, it's not clear to me what particular approach makes most sense for > pushing upstream.Why this needs to be "pushed" upstream in the first place? Isn't it simpler/easier/whatever to just require klibc to be present on the build system for kernel? If klibc is "sufficiently" independent of the kernel (is it? I see no reason it shouldn't), why it should go with kernel? Just point your CONFIG_INITRAMFS_SOURCE to some klibc directory tree and be done with it, no need to distribute/build klibc with kernel.. Thanks. /mjt