Linus,
I am submitting this for inclusion into the pre-2.6 tree.
You've said 'yes' to initramfs. Maybe you'll like this
'ready to go' solution better.
A patch against 2.5.45 is here:
http://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/2.5.45/initrd_dynamic-2.5.45.diff.gz
It has been tested as well I can as 2.5.45 has a new bug in rd.c
with initrd deallocation. It was tested with 2.5.44, A-1, no problems.
To find out if you 'like it' you can view the primary
files involved here: They are already 'post-patched' 2.5.45:
http://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/2.5.45/do_mounts.c
http://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/2.5.45/initrd.c
http://ftp.psychosis.com/linux/initrd-dyn/kernelpatches/2.5.45/untar.c
What this patch does:
One or more tar and/or tar.gz archives can be loaded by a
bootloader, and they will be extracted sequencially to a
tmpfs (ramfs) root.
Rewrote the initrd handling and made the code more modular.
All legacy initrd functions have been removed from do_mounts.c.
do_mounts.c has been greatly cleaned up. (Now ~10K)
All new and legacy initrd related functions are now in initrd.c
We id both un/compressed images/archives and act accordingly.
Better error checking and printk messages
What this has that initramfs doesn't:
Clean up and rewrite of the system already in place.
The use of tar archives
Multiple archive support
Works good, right now
What initramfs has that this doesn't:
Load image from a 'linked' kernel location.
Uses CPIO archives
Why you should include this as the new tmpfs(ramfs) initial root
loading solution:
More robust implementation.
Useful error checking and user output messages
The ability to leave legacy initrd infrasturture
inplace via #ifdef's if needed.
do_mounts.c gets scrubbed up. (Until the day it's purged,
why not!?!)
Tar is in wide spread (general audiences) use. CPIO is not.
People have said Tar is bloated/complex.
Tar == Read header. Determine type. Write file.
CPIO == Read header. Determine type. Write file.
(Look at untar.c. un-cpio'ing is no different. You decide.)
I was here first. ; ) (The first version of this was made
in January 1998 using a minixfs on /dev/ram0)
What I still need to do:
Add loading 'linked image' support ala initramfs (minor work)
Clean some minor things. (Purge mount_tmpfs_root() )
Update docs and comments
Test legacy 'load_ramdisk' style floppy support
Purge anything people want gone (Legacy linuxrc root pivot, etc)
ALL OF THESE WILL BE DONE WITHIN *DAYS* IF YOU SHOW INTEREST
What you should do if you have no desire in this at all:
Please, tell Dave 'no, not at all' so he can go to bed already!
Dave Cinege wrote:
>What this has that initramfs doesn't:
> Clean up and rewrite of the system already in place.
> The use of tar archives
> Multiple archive support
> Works good, right now
>
>
indeed :)
>What initramfs has that this doesn't:
> Load image from a 'linked' kernel location.
> Uses CPIO archives
>
>
early userspace, which is the whole point of the exercise.
We want to move a bunch of stuff _out_ of the kernel to userspace.
Jeff
On Friday 01 November 2002 6:19, Jeff Garzik wrote:
> >What initramfs has that this doesn't:
> > Load image from a 'linked' kernel location.
> > Uses CPIO archives
>
> early userspace, which is the whole point of the exercise.
>
> We want to move a bunch of stuff _out_ of the kernel to userspace.
WHEN THAT DAY COMES....this will cleanly support it.
Infact it supports it now...just not from a 'linked' archive.
(We'll see if I can change that tonight)
Right now 'early userspace' is a concept not a codeset.
(Unless someone is hiding it from me...I did ask you where
it is...) There is no standardized archive that goes there.
Until it is developed the current initramfs code does nothing
but eat kernel space.
Unlike the current initramfs solution this code provides a
smooth transitional base that can CLEANLY be merged back into the
2.4.xx branch. In a few minutes I can make an #ifdef of the
legacy floppy/block loading code. (Infact I think I'll do
just that, and submit an update. Until I hear 'no' from Linus,
I'm going to punish myself and proceed forward.)
I'm sitting on the idea 'past performance will yeild similar
present results'. *14 months* ago I tried to get Initrd Dynamic
into the 2.4 kernel.
I was told last YEAR 'There is no point. Initramfs is coming.'
Unlike last year the version I'm submitting now is a crystal clean
merge.
Like last YEAR I'm told 'There is no point. Initramfs is coming.'
Well there is a point:
Initrd Dynamic does the job better and it's working now!
Dave
--
The time is now 22:48 (Totalitarian) - http://www.ccops.org/