mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <miltonm@bga.com> Milton Miller
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCHES] initramfs merge, part 1 of N
Date: Sat, 2 Nov 2002 04:51:29 -0600 (CST)	[thread overview]
Message-ID: <200211021051.gA2ApTZ17164@sullivan.realtime.net> (raw)
In-Reply-To: <3DC38939.90001@pobox.com>


> Items For Discussion
> 
> #1 - shared kinit
> 
> "kinit" is _the_ early userspace binary -- but not necessarily the only
> one. Peter Anvin and Russell King have several binaries in the klibc
> tarball, gzip, ash, and several smaller utilities. Peter also put work
> into making klibc a shared object -- that doesn't need an shlib loader.
>  It's pretty nifty how he does it, IMO: klibc.so becomes an ELF
> interpreter for any klibc-linked binaries. klibc-linked binaries are,
> to the ELF system, static binaries, but they wind up sharing klibc.so
> anyway due to this trick.
> 
> Anyway, there is a certain elegance in adding coding to kinit instead of
> an explosion of binaries and shell scripts. The other side of that coin
> is that with elegance you sacrifice some ease of making changes. I am
> 60% certain we want a shared klibc and multiple binaries, but am willing
> to be convinced in either direction. If you think about it, there _are_
> several benefits to leaving kinit as the lone binary in the stock kernel
> early userspace build, so the decision is not as cut-n-dry as it may
> immediately seem. 


One idea I experimented some time ago with (and can revive after
some sleep) is, rather than interpreting cpio in the kernel, objcopy
a binary into a init and copy that into pagecache in a ramfs/libfs
file system.   The population was all initfunctions, trying to make
it disappear at runtime.  /dev/initrd was left for userspace to
expand the rest of the loaders.  With libfs, the write code reinstated
so standard directories, device nodes, console and initrd nodes
can be created and opened in userspace, further shrinking the static
linked-in code.

This argues that this initial code is unshared and uncompressed
(or rather, compressed like the rest of the kernel); for shared we
would have to copy a couple of pieces this way.  It traded off a
table of offset,length,mode,name with cpio headers and parsing.

I had this running on 2.4.19-pre10 (around the time of the kernel
summit, just before the fixed directory link counts went in) with
busybox.  (I seperated the 2.4 compat vs 2.5 stuff at that time).

Comments?

milton

  parent reply	other threads:[~2002-11-02 10:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-02  8:13 Jeff Garzik
2002-11-02  8:18 ` Jeff Garzik
2002-11-02  8:42 ` Aaron Lehmann
2002-11-02  8:46   ` Jeff Garzik
2002-11-02  8:50     ` H. Peter Anvin
2002-11-02 19:01   ` Linus Torvalds
2002-11-02 12:07     ` H. Peter Anvin
2002-11-02 20:24     ` Alexander Viro
2002-11-02 23:46     ` Dave Cinege
2002-11-02 10:51 ` miltonm [this message]
2002-11-02 17:12 ` Matt Porter
2002-11-02 12:14   ` H. Peter Anvin
2002-11-02 20:37     ` an idling kernel Anu
2002-11-02 22:16       ` Jos Hulzink
2002-11-03  0:43       ` identifying the idling kernel and kernel hacking Anu
2002-11-04 19:16       ` an idling kernel Werner Almesberger
2002-11-02 20:37     ` [BK PATCHES] initramfs merge, part 1 of N Alexander Viro
2002-11-02 23:36     ` Matt Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200211021051.gA2ApTZ17164@sullivan.realtime.net \
    --to=miltonm@bga.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®