klibc - Sep 2010 - + init-add-sys-wrapperh.patch added to -mm tree

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.

	Arnd

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.