RFC: Kill off addRamDisk

David Gibson david at gibson.dropbear.id.au
Mon Aug 1 16:31:07 EST 2005


On Mon, Aug 01, 2005 at 08:19:04AM +0200, Olaf Hering wrote:
>  On Thu, Jul 28, David Gibson wrote:
> 
> > Can anyone think of any problems with abolishing addRamDisk - the icky
> > iSeries-specific method of loading an initial ramdisk.  If not, I'll
> > push this to Andrew.
> > 
> > iSeries has a home-built method of attaching an initial ramdisk, which
> > relies on an addRamDisk helper program poking the data, location and
> > offset into the vmlinux after build.  Both SLES and RHEL now use the
> > normal initramfs mechanisms instead of the iSeries specific initrd on
> > 2.6 kernels, so let's get rid of this obsolete mechanism.
> 
> How is the initramfs vs. loop mounted file related?
> Maybe I miss the point, how is the initrd content passed to the kernel
> during boot after your change? pseries has its own section in zImage.initrd,
> and yaboot passes just the initrd memrange in r3+r4. 

Yeah, check the rest of the thread - I realized I was mistaken and
that the initramfs, too, needed addRamDisk.  I've sent a new patch
which removes the fixed address from the NACA without eliminating
addRamDisk.  Changing addRamDisk to use objcopy instead of direct
poking might be something to look at later.

> Can the $O/usr/initramfs_data.cpio.gz file linked later into the vmlinux
> file? I see an '.init.ramfs' section there, perhaps you want to replace
> the addRamdisk binary with an addRamdisk shell script which calls
> objcopy. But this way we lose the overlay feature.

I'm not sure what you mean by "the overlay feature".

> A simple 'find . | cpio -H newc --create | gzip -9 > tmp_initrd.gz'
> would not work anymore as unprivileged user because mknod cant be done
> that way.

How does the method used to combine the vmlinux and initrd have any
bearing on what we can do when generating the initrd?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/people/dgibson



More information about the Linuxppc64-dev mailing list