What happened to this one? Is it in -mm?
Thanks!
--
Al
Al Boldi wrote:
> Bodo Eggert wrote:
> > Al Boldi <[email protected]> wrote:
> > > Bodo Eggert wrote:
> > >> This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to
> > >> use tmpfs instead of ramfs". All the fame belongs to him, the bugs
> > >> belong to me.
> > >
> > > Actually, my patch was a rework of John Zielinski's
> > > http://marc.info/?l=linux-kernel&m=107013630212011&w=4 patch, so the
> > > credit really goes to him.
> > >
> > >> Signed-Off-By: Bodo Eggert <[email protected]>
> > >>
> > >>
> > >> diff -Xdontdiff -pruN linux-2.6.22.base/fs/Kconfig
> > >> linux-2.6.22.tmpfsroot/fs/Kconfig --- linux-2.6.22.base/fs/Kconfig
> > >> 2007-07-12 14:05:16.000000000 +0200 +++
> > >> linux-2.6.22.tmpfsroot/fs/Kconfig 2007-07-12 15:10:09.000000000 +0200
> > >> @@ -989,6 +989,22 @@ config TMPFS_POSIX_ACL
> > >
> > > Setting this in fs/Kconfig is way to deep, and too far away from the
> > > initramfs Kconfig, which makes it obscure.
> >
> > If it were under general setup, you'd have to enter fs to select tmpfs,
> > enter general setup to replace ramfs, and re-enter fs to disable ramfs.
> > I consider making people do that to be an evil deed.
>
> That's easy to fix, just change "depends on" to "select" in Kconfig.
>
> > The current position is very convenient, ramfs is below tmpfs, and while
> > you go from top to the bottom, you can enable tmpfs,
> > tmpfs-replaces-ramfs and ramfs=n.
> >
> > >> If you don't know what Access Control Lists are, say N.
> > >>
> > >> +config TMPFS_ROOT
> > >> + bool "Use tmpfs instrad of ramfs for initramfs"
> > >
> > > Check typo.
> > >
> > >> + depends on TMPFS
> > >
> > > Should probably depend on SHMEM too.
> >
> > Sounds reasonable.
> >
> > >> @@ -1003,7 +1019,7 @@ config HUGETLB_PAGE
> > >> def_bool HUGETLBFS
> > >>
> > >> config RAMFS
> > >> - bool
> > >> + bool "Ramfs file system support" if TMPFS_ROOT
> > >
> > > What's wrong with the original Kconfig of making this tristate?
> >
> > I tested =m, found it not to compile because of a nonexported __symbol
> > and decided it wasn't worth the effort of adding another export while
> > other people struggle to reduce their number.
>
> Ok.
>
> > >> diff -Xdontdiff -pruN linux-2.6.22.base/mm/shmem.c
> > >> linux-2.6.22.tmpfsroot/mm/shmem.c --- linux-2.6.22.base/mm/shmem.c
> > >> 2007-07-12 14:05:25.000000000 +0200 +++
> > >> linux-2.6.22.tmpfsroot/mm/shmem.c 2007-07-12 15:01:32.000000000 +0200
> > >> @@ -2369,6 +2369,8 @@ static void init_once(void *foo, struct
> > >>
> > >> static int init_inodecache(void)
> > >> {
> > >> + if (shmem_inode_cachep)
> > >> + return 0;
> > >> shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
> > >> sizeof(struct shmem_inode_info),
> > >> 0, 0, init_once, NULL);
> > >> @@ -2582,6 +2584,34 @@ put_memory:
> > >> return ERR_PTR(error);
> > >> }
> > >>
> > >> +#ifdef CONFIG_TMPFS_ROOT
> > >> +static int rootfs_get_sb(struct file_system_type *fs_type,
> > >> + int flags, const char *dev_name, void *data, struct vfsmount
> > >> *mnt) +{
> > >> + return get_sb_nodev(fs_type, flags|MS_NOUSER, data,
> > >> shmem_fill_super, + mnt);
> > >
> > > Setting the MS_NOUSER flag will make this invisible to df (diskfree).
> >
> > Which is obviously a bad thing for my cause, but good if you'd boot a
> > normal system. Is there any way out?
>
> Just remove the MS_NOUSER flag. Normal systems would want to umount it
> after pivoting, so it won't be visible then.
>
> > >> +}
> > >> +
> > >> +/*static struct super_block *rootfs_get_sb(struct file_system_type
> > >> *fs_type, + int flags, const char *dev_name, void *data)
> > >> +{
> > >> + return get_sb_single(fs_type, flags, data, shmem_fill_super);
> > >> +}*/
> > >
> > > You commented this out, probably asking for clarification: IIRC, it's
> > > get_sb_single instead of get_sb_nodev, because tmpfs can be mounted
> > > more than once and thus needs to be reference counted.
> >
> > No, I had left it there accidentially. Your comment tells me it was ment
> > to happen.
>
> Thanks!
>
> --
> Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
