Re: [PATCH 2/3][try 1] init: enable system-on-initramfs: root-on-tmpfs

[Bodo Eggert]

Al Boldi <a1426z@xxxxxxxxx> wrote:
> Bodo Eggert wrote:

Please reply-to-all, I'm not subscribed, but reading through a news gateway.

>> 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 <7eggert@xxxxxx>
>>
>>
>> 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.

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.

>> 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?

>> +}
>> +
>> +/*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.
-- 
If at first you don't succeed call in an air-strike. 

Friß, Spammer: zbyUv@xxxxxxxxxxxxxxxxxxxxxxxxxx J@xxxxxxxxxxxxxxxxxxxxxxx
 NS6uqbvhd9@xxxxxxxxxxxxxxxxxxxx QcPun@xxxxxxxxxxxxxxxxxxxxxxx
-
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/