On 10 Feb 2022, at 17:54, NeilBrown wrote:
On Thu, 10 Feb 2022, Benjamin Coddington wrote:
Yes, but even better than having the tool do the writing is to have
udev do
it, because udev makes the problem of when and who will execute this
tool go
away, and the entire process is configurable for anyone that needs to
change
any part of it or use their own methods of generating/storing ids.
I really don't understand the focus on udev.
Something, somewhere, deliberately creates the new network namespace.
It then deliberately configures that namespace - creating a virtual
device maybe, adding an IP address, setting a default route or
whatever.
None of that is done by udev rules (is it)?
Setting the NFS identity is just another part of configuring the new
network namespace.
udev is great when we don't know exactly when an event will happen,
but
we want to respond when it does.
That doesn't match the case of creating a new network namespace. Some
code deliberately creates it and is perfectly positioned to then
configure it.
I think there's so many ways to create a new network namespace that we
can't
reasonably be expected to try to insert out problem into all of them.
Handling the event from the kernel allows us to make a best-effort
default
attempt.
udev is async. How certain can we be that the udev event will be
fully
handled before the first mount attempt?
Good point. We can't at all be certain.
We can start over completely from here..
We can have mount.nfs /also/ try to configure the id.. this is more
robust.
We can have mount.nfs do a round of udev settle..
Are there other options?
Ben
