[RFC PATCH 0/8] namespace-aware configfs
Christian Brauner
brauner at kernel.org
Wed Jun 17 04:58:36 PDT 2026
> Open Issues:
> - I've added a new function 'mnt_clone_direct()' to clone the vfsmount
> entry (the original code just did a simple_pin_fs()). Not sure if
> that's correct. Christian?
I think we can put that issue aside for a second as there are a few
bigger design questions.
> - The current cloning mechanism is not really a hierarchy, but rather
> always using the default namespace to find registered subsystems.
> Meaning you can only call 'register_subsystem()' for the default
> namespace. But then one shouldn't call modprobe in a container, so
> that's okay I guess.
I'm not sure I follow what this is trying to say, sorry.
> - The original content of the configfs remains visible even from
> within the container, and the new 'mount' will just overlay that.
I again fail to understand what precisely this means.
> Ideally I would have the container start off with an empty
> /sys/kernel/config to avoid configuration issues. But again I've
> no idea how to do that (or if it's even possible).
Shouldn't be a problem to implement this. Just means more work.
So the rough concept in my head would be that configfs is a
multi-instance filesystem that remembers the namespaces it was mounted
similar to how kernfs allows to be tagged with namespaces. It then only
shows/allows registration of subsystems that match the relevant
namespace tags.
The challenge I see is that configfs shows subsystems that may be tied
to different namespaces.
More information about the Linux-nvme
mailing list