Re: [PATCH] use tmpfs for rootfs v3

From: Bodo Eggert
Date: Mon Oct 20 2008 - 14:13:32 EST


On Sun, 19 Oct 2008, Mike Frysinger wrote:
> On Fri, Oct 17, 2008 at 07:16, Bodo Eggert wrote:

> > This patch allows chosing tmpfs instead of ramfs for the root filesystem.
> > Having tmpfs is usefull for running systems from RAM, because it does not
> > risk deadlocking the system and possibly allows swapping. Using tmpfs
> > increases the kernel by 10 bytes on x86_64.
>
> great option, thanks
>
> > --- linux-2.6.27.2-numlock/fs/Kconfig 2008-10-10 13:18:34.000000000 +0200
> > +++ linux-2.6.27.3-tmpfs/fs/Kconfig 2008-10-11 15:42:21.000000000 +0200
> > @@ -953,6 +953,27 @@ config TMPFS_POSIX_ACL
> >
> > If you don't know what Access Control Lists are, say N.
> >
> > +config TMPFS_ROOT
> > + bool "Use tmpfs instrad of ramfs for initramfs"
> > + depends on TMPFS && SHMEM
> > + default n
> > + help
> > + This replaces the ramfs used for unpacking the cpio images
> > + with tmpfs.
> > +
> > + If unsure, say N
>
> this should be init/Kconfig and depend on BLK_DEV_INITRD i think. and
> then update the comment to talk about the initial filesystem rather
> than cpio images.

Maybe, but then you'd have to go to filesystems->pseudo-fs to enable tmpfs,
then to i-don't-remember to set it as the rootfs, and then back to
fs->pseudo-fs to unselect ramfs.

Thinking of it as a tmpfs option makes it much easier to use.

> > +config RAMFS
> > + bool "Ramfs file system support" if TMPFS_ROOT
>
> if you have initramfs support disabled, then you should be able to
> disable RAMFS as well. so perhaps the depend should read like:
> if BLK_DEV_INITRD && TMPFS_ROOT || !BLK_DEV_INITRD

No, since a kernel not having initcpio support will mount rootfs anyway,
create some directories and special files and use them to open the console
and to mount the real root into.
--
The enemy diversion you have been ignoring will be the main attack.
--
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/