Re: [PATCH 5/5] initmpfs v2: Use initramfs if rootfstype= or root=specified.
From: Rob Landley
Date: Fri Jul 26 2013 - 00:12:33 EST
On 07/19/2013 02:57:18 PM, Andrew Morton wrote:
On Tue, 16 Jul 2013 16:45:39 -0700 (PDT) Rob Landley
> Command line option rootfstype=ramfs to obtain old initramfs
> and use ramfs instead of tmpfs for stub when root= defined (for
Could we get a Documentation/kernel-parameters.txt update please?
Sorry for the delay, traveling. Behind on email...
"rootfstype" is already documented in kernel parameters:
rootfstype= [KNL] Set root filesystem type
I just applied the existing definition to initramfs now that it has
more than one filesystem option there. Do you want me to add a special
case here to say that rootfstype= still works when the root filesystem
is initramfs? Or would it instead make more sense to add:
Signed-off-by: Rob Landley <rob@xxxxxxxxxxx>
Document that rootfstype= applies to initmpfs too.
@@ -79,6 +79,9 @@ to just make sure certain lists can't become empty.
Most systems just mount another filesystem over rootfs and ignore
amount of space an empty instance of ramfs takes up is tiny.
+If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
+To force ramfs, add "rootfstype=ramfs" to the kernel command line.
What is initramfs?
(What I _didn't_ do yet is hook up rootflags= to initmpfs, so you can
specify size= as something other than 50%. Partly because if you have
an empty cpio archive and the rootflags= applies to ext3 or something,
those flags could potentially confuse tmpfs with unknown options and
throw errors. And partly because mount -o remount,size=20% works fine
after the fact, so it's not time critical and I easily can do a
follow-up patch. The one potential downside is if you want to have a
cpio archive eat more than 50% of the kernel's memory, it'll fail to
extract into tmpfs with the size limits. But the rootfstype=ramfs
downgrade also works around that for now...)
There are a number of follow up patches I could do, but the basic
functionality doesn't depend on them...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/