On 07/19/2013 02:57:18 PM, Andrew Morton wrote:
On Tue, 16 Jul 2013 16:45:39 -0700 (PDT) Rob Landley
<r...@landley.net> wrote:
> Command line option rootfstype=ramfs to obtain old initramfs
behavior,
> and use ramfs instead of tmpfs for stub when root= defined (for
cosmetic
> reasons).
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 <r...@landley.net>
Document that rootfstype= applies to initmpfs too.
--- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@@ -79,6 +79,9 @@ to just make sure certain lists can't become empty.
Most systems just mount another filesystem over rootfs and ignore
it. The
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
default.
+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...
Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
