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

Arnd Bergmann arnd at arndb.de
Sat Sep 18 02:44:22 PDT 2010

On Friday 17 September 2010, Al Viro wrote:
> IMO this is blatantly wrong.  This code already runs with KERNEL_DS.
> All these games with set_fs() are completely bogus, since allowing
> normal kernel code to issue random syscalls had never been an intention.

Well, AFAICT kernels have pretty much always done direct syscalls in some
places. Originally this was actually going through the user space
syscall entry path which I removed a few years ago for kenrel users.

> 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.


More information about the klibc mailing list