Bodo Eggert wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Bodo Eggert wrote: > > Please reply-to-all, I'm not subscribed, but reading through a news > gateway.
Same here. The problem is, I have no idea who's on the cc, and expected you to be on the list. Sorry. > >> 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/
