[klibc] + init-add-sys-wrapperh.patch added to -mm tree

[H. Peter Anvin]

On 09/18/2010 02:44 AM, Arnd Bergmann wrote:
> 
>> IOW, this is a userland code that had been subjected to trivial modifications
>> to run in kernel, just before the execve() of init.  The only reason why
>> we do not simply turn that into a userland binary and execve() that instead
>> is that we don't want to complicate kbuild.  Perhaps we ought to bite the
>> bullet and just copy syscall-calling code from e.g. klibc; that would take
>> care of that mess for good.  Link the resulting static ELF binary as one
>> more initramfs chunk and process it first.  Then replace all that stuff
>> kernel-side with a single unconditional execve("/kinit",...) and let it
>> do the rest of work.
> 
> Wasn't this the original intention of hpa's work on klibc? If we want
> to run this in user space, we need some library code to go along with
> it, and it would be really bad to require being able to link statically
> against the system libc in order to build a kernel.
> 

That indeed was *exactly* the intent with klibc (and Al's input was the
main motiation for starting the project in the first place.)  We had
everything working, including kbuild integration, do make that all work.
 There is a kinit binary in the klibc tree, which is exactly the
in-kernel code (well, as of a few years ago) converted to real userspace.

I still think klibc is a good idea, and I'd be happy to update the
integrated klibc build if people (especially Linus) now thinks it's
worthwhile.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.