I was pointing out it's been done before.
I'd prefer autodetecting it so new namespaces and the base namespace
don't have magic policy _or_ require different mount invocations. An
ability to change the default for a value is less appealing than not
needing the value in the first place.
And changing the default would probably have to be per-container anyway
to be useful. (Which isn't _quite_ the same as per-namespace since you
can chroot without CLONE_NEWNS.)
(I keep thinking back to web service providers offering cheap web
hosting "with root access" via openvz containers and such. They're
administering their own boxes, but aren't big iron guys. This is yet
another thing for them to understand that didn't apply to the linux box
they have at home, and I'm just wondering if there's a way they don't
have to.)
You can still provide a specific location with "-o rpcmount=/blah",
correct? So this isn't restricting it, this is autodetecting the
default value, using the visible mount point of the appropriate type.
There is in that the root context doesn't need to have this mounted, and
new namespaces do. So there's an existing association between a LACK of
a namespace and a different default behavior.
My understanding (correct me if I'm wrong) is that the historical
behavior is that there's only one, and it doesn't actually live anywhere
in the filesystem tree. You're adding a special location. I'm
wondering if there's any way for that location not to be special.
I'm talking about associating a default rpc_pipefs instance with a
namespace, which it seems to me you're already doing by emulating the
legacy behavior. Before you CLONE_NEWNS you get a magic default mount
that doesn't exist in the tree. After you CLONE_NEWNS you get something
like -EINVAL unless you supply your own default. (I'm actually not sure
why new namespaces don't fall back to the magic global one...)
I'm suggesting that if the user doesn't specify -o rpcmount then the
default could be the first rpc_pipefs mount visible to the current
process context, rather than a specific path. Logic to do that exists
in the proc/self/mounts code (which I'm reading through now...).
(Your 00/12 post doesn't actually explain what can be _different_ about
the various instances of rpc_pipefs, and hence why you'd want to mount
it multiple times. I'm still coming up to speed on the guts of NFS.
The use case I'm trying to fix involves containers with different
network routing than the host, and this looks like potentially part of
the solution to that, but I'm still putting together enough context to
work out how....)
Rob
--
