[PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[David Cinege]

Linus and Alan, 

Initrd Dynamic is mature, stable, well mantained code. It makes very minimal 
impact to the current source tree, segrigating itself to it's own source 
files. It is fully backwards compatible with current initrd operations.

Please consider it for inclusion in the next 2.4 kernel release.

2.4.9 kernel patch
ftp://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/initrd-dyn_4.2_2.4.9.diff.gz

2.0 and 2.2 kernel patches:
ftp://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/

More info
ftp://ftp.psychosis.com/linux/initrd-dyn/README
-----------------------------------------------------------
About:

Current Release: 4.2

Initrd Dynamic supercedes Initrd Archive. This function subset was
first written in January 1998 and has progressed in features since
then. Developed for the Linux Router Project, it is in wide spread
use in various Linux embedded systems and thin OS's.


kernelpatches/
	Patches for Linux 2.0, 2.2, and 2.4 kernels.
	The kernel patches include the base files, required changes to rd.c
	and configuration files, and a fix in main.c to allow /linuxrc
	even if root=/dev/ram0. (Long standing bug)
-------------------------------------------------------------
What is it:

Initial RAM disk dynamic creation support
CONFIG_BLK_DEV_INITRD_DYN
  Initrd Dynamic allows you to use tar.gz archive(s) instead of those
  nasty raw  images. It works by dynamically creating a filesystem at
  boot, mounting it as '/', then extracting the archive(s) loaded into
  the initrd memory space. If your bootloader can load multiple archives
  sequentially (IE a patched GRUB) all archives will be extracted in the
  order they where loaded.

  Optionally Initrd Dynamic can create the /dev directory and some
  failsafe console files.

  You must select at least one of the available filesystems below.
  You probably want to use tmpfs if it's available in your kernel.

  The kernel parameter to specify options is:
  initrd_dyn=fstype[,fssize[k|m]][,mkdev]

  fstype == One of the supported dynamic mkfs filesystems.

  fssize ==  Limits the size of the filesystem created.
	tmpfs: If not speced it's equal to the real memory space.
  	minix: If not speced it's equal to ramdisk_size.

  mkdev  == /dev is created after archive untar. Useful even if devfs=mount.

  Examples:
  initrd_dyn=tmpfs load_ramdisk=1
  initrd_dyn=tmpfs,4096k load_ramdisk=1
  initrd_dyn=tmpfs,16m,mkdev load_ramdisk=1

  initrd_dyn=minix,8m ramdisk_size=20480 root=/dev/ram0 load_ramdisk=1
  initrd_dyn=minix,,mkdev root=/dev/rd/0 load_ramdisk=1

Initial RAM disk tmpfs auto filesystem support
CONFIG_BLK_DEV_INITRD_DYN_TMPFS
  Specing initrd_tar=tmpfs[,fssize] will have the kernel dynamically
  mount a tmpfs filesystem as the root. Spec a normal tar.gz file for
  the boot loader to load as the initrd root archive.

Initial RAM disk minix auto filesystem support
CONFIG_BLK_DEV_INITRD_DYN_MINIX
  Specing initrd_tar=minix[,fssize] will have the kernel dynamically
  create a minix filesystem on /dev/ram0 at boot time. Spec a normal
  tar.gz file for the boot loader to load as the initrd root archive.

Re: [PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[Alexander Viro]

On Sun, 23 Sep 2001, David Cinege wrote:

> Linus and Alan, 
> 
> Initrd Dynamic is mature, stable, well mantained code. It makes very minimal 
> impact to the current source tree, segrigating itself to it's own source 
> files. It is fully backwards compatible with current initrd operations.
> 
> Please consider it for inclusion in the next 2.4 kernel release.

Sigh...  With initramfs it can be done in userland.  _Please_, let's stop
adding complexity to already ridiculously bloated late boot stages.
David, no offence, but let's do it the right way.

Re: [PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[David Cinege]

On Sunday 23 September 2001 0:41, Alexander Viro wrote:
> >
> > Please consider it for inclusion in the next 2.4 kernel release.
>
> Sigh...  With initramfs it can be done in userland. 

Using Initrd Dynamic a person can boot with a ramdisk as their primary
root, populating it with tar.gz archive(s). Making 'image' changes works
very well and in a modular way. (IE root.tgz, etc.tgz) 

With this release you can now forgo an internal mkfs on /dev/ram0 before 
archive extraction and go straight to a truly dynamic tmpfs VFS as the root
without the minix FS limitations. 

Now, could you please explain to me how the hell you boot to a tmpfs
root from userland!?!? This feature *creates* your userland.

Maybe you're just confused what this feature does. Maybe you've never
worked with systems that run a volatile root. Maybe you've just never made
a boot disk.

Maybe you even think it's sane to compile userland into the kernel? <snicker 
snicker> I just looked at your initramfs. From what I see it's the same 
scheme I used to use In the Linux Router Project before I wrote 
initrd-archive. Except I did it *entirely* in userland back in 1997. It 
sucked. Badly.

> _Please_, let's stop
> adding complexity to already ridiculously bloated late boot stages.

It's funny you've refered to my patch as bloated. What you've wrote (which is 
a limited solution) weighs in at ~122k. Initrd Dynamic is ~35K complete and 
that includes ~7K of mkfs_minix, which can be removed when use Linux 2.4 with 
tmpfs (and ~2K of Configure.help : > ). Compiled up it add only ~3K to the 
kernel size, and as for boot complexity, I agree lets reduce it. Leave it
up to the bootloader to populate initrd memory space, or let a specific 
driver tie the initrd file handle to a device to load from. Initrd Dynamic
is made to work this way and is (should be) entirely platform independant
code.

One day I hope someone finally implements loading kernel modules from 
'initrd' type memory space, again leaving the job of getting them their to 
the boot loader. (Actually it's called the multi boot standard and GRUB boot 
loader has supported it for 3(?) years.)

> David, no offence, but let's do it the right way.

It is done right. Infact, I'm proud that this release finally has implemented 
it to perfection for the purposes it was designed. It took 3 years
to get to this point of a completly dynamic, modular, ram based root.

It never fails, post a patch to kernel and they come out of the wood work 
with delusional bitching. This is one reason I sat on releases for 9 months.
BTW Offence intended...

Dave

Re: [PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[Alexander Viro]

On Sun, 23 Sep 2001, David Cinege wrote:

> Now, could you please explain to me how the hell you boot to a tmpfs
> root from userland!?!? This feature *creates* your userland.

And that's _all_ you need on the kernel side.

> Maybe you're just confused what this feature does. Maybe you've never
> worked with systems that run a volatile root. Maybe you've just never made
> a boot disk.

> Maybe you even think it's sane to compile userland into the kernel? <snicker 
> snicker> I just looked at your initramfs. From what I see it's the same 
> scheme I used to use In the Linux Router Project before I wrote 
> initrd-archive. Except I did it *entirely* in userland back in 1997. It 
> sucked. Badly.

Which somewhat contradicts the paragraph above (and common sense, while
we are at it).  BTW, I would really love to hear how TF did you manage
a non-breakable chroot jail 4 years ago _and_ in userland.

> > _Please_, let's stop
> > adding complexity to already ridiculously bloated late boot stages.
> 
> It's funny you've refered to my patch as bloated. What you've wrote (which is 
> a limited solution) weighs in at ~122k. Initrd Dynamic is ~35K complete and 

Not patch.  The late-boot logics itself.  BTW, while we are comparing patch
sizes, count how much is added and how much is removed.

> > David, no offence, but let's do it the right way.
> 
> It is done right. Infact, I'm proud that this release finally has implemented 
> it to perfection for the purposes it was designed. It took 3 years
> to get to this point of a completly dynamic, modular, ram based root.
> 
> It never fails, post a patch to kernel and they come out of the wood work 
> with delusional bitching. This is one reason I sat on releases for 9 months.
> BTW Offence intended...

... and failed.  Frankly, it takes more than that to offend.  As a flame
it's below mediocre.

As for the code... _all_ you need on the kernel side is "unpack <some_archive>
to ramfs/tmpfs and do exec()".  That's it.  The rest can be done in userland.
That includes the logics with loading ramdisk from initrd/floppies, handling
nfsroot, choosing final root device, yodda, yodda.  And yes, I consider
ripping that logics from the kernel space a Good Thing(tm).  Among other
things, it allows to replace deeply rotten code with invoking a couple of
syscalls.  I have no problems with using your code as a base for that, but
that should be done.  Current fs/super.c::mount_root() should go.  Again,
I've no problems with keeping that in form of sys_foo() called from the
kernel space (initramfs is incremental to exactly that - see init/do_mounts.c
in namespaces-patch).  But let's get all that logics into one place and
do it in clean way.  Even if we rip 90% of it in 2.5 (loading ramdisk from
multiple floppies with requests to change them - b0rken on powerpc, BTW;
or the lovely way we sometimes forget to ask to eject the damn thing -
have fun with that on Sun boxen), I'd rather see it done when we have
the sucker cleanly separated from the rest of the kernel.  Which is more
than 35Kb - just removing all that code from the multiple places it lives
now will take more.  Grep around for wait_for_keypress() and you'll see
what I mean.

Re: [PATCH] Initrd Dynamic v4.2 - New Feature: Tmpfs root support

[Jeff Garzik]

On Sun, 23 Sep 2001, Alexander Viro wrote:
> As for the code... _all_ you need on the kernel side is "unpack <some_archive>
> to ramfs/tmpfs and do exec()".  That's it.  The rest can be done in userland.
> That includes the logics with loading ramdisk from initrd/floppies, handling
> nfsroot, choosing final root device, yodda, yodda.  And yes, I consider
> ripping that logics from the kernel space a Good Thing(tm).

...as do others...