On Fri, May 21, 2021 at 08:41:55AM +0800, Menglong Dong wrote:
> Hello!
>
> Thanks for your reply!
>
> On Fri, May 21, 2021 at 5:41 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> >
> > Can't docker instead allow to create containers prior to creating
> > your local docker network namespace? Not that its a great solution,
> > but just worth noting.
> >
>
> That's a solution, but I don't think it is feasible. Users may create many
> containers, and you can't make docker create all the containers first
> and create network namespace later, as you don't know if there are any
> containers to create later.
It doesn't seem impossible, but worth noting why inside the commit log
this was not a preferred option.
> > > struct file_system_type rootfs_fs_type = {
> > > .name = "rootfs",
> > > - .init_fs_context = rootfs_init_fs_context,
> > > + .init_fs_context = ramfs_init_fs_context,
> >
> > Why is this always static now? Why is that its correct
> > now for init_mount_tree() always to use the ramfs context?
>
> Because the root mount in init_mount_tree() is not used as rootfs any more.
We still have:
start_kernel() --> vfs_caches_init() --> mnt_init() -->
mnt_init()
{
...
shmem_init();
init_rootfs();
init_mount_tree();
}
You've now modified init_rootfs() to essentially just set the new user_root,
and that's it. But we stil call init_mount_tree() even if we did set the
rootfs to use tmpfs.
> In do_populate_ro
> tmpfs, and that's the real rootfs for initramfs. And I call this root
> as 'user_root',
> because it is created for user space.
>
> int __init mount_user_root(void)
> {
> return do_mount_root(user_root->dev_name,
> user_root->fs_name,
> root_mountflags,
> root_mount_data);
> }
>
> In other words, I moved the realization of 'rootfs_fs_type' here to
> do_populate_rootfs(), and fixed this 'rootfs_fs_type' with
> ramfs_init_fs_context, as it is a fake root now.
do_populate_rootfs() is called from populate_rootfs() and that in turn
is a:
rootfs_initcall(populate_rootfs);
In fact the latest changes have made this to schedule asynchronously as
well. And so indeed, init_mount_tree() always kicks off first. So its
still unclear to me why the first mount now always has a fs context of
ramfs_init_fs_context, even if we did not care for a ramdisk.
Are you suggesting it can be arbitrary now?
> Now, the rootfs that user space used is separated with the init_task,
> and that's exactly what a block root file system does.
The secondary effort is a bit clearer, its the earlier part that is not
so clear yet to me at least.
Regardless, to help make the changes easier to review, I wonder if it
makes sense to split up your work into a few patches. First do what you
have done for init_rootfs() and the structure you added to replace the
is_tmpfs bool, and let initialization use it and the context. And then
as a second patch introduce the second mount effort.
Luis
