Re: [libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
Dan Smith wrote:
DL> Did I missed something ?
I think I misinterpreted your original statement, so let me go back.
You said:
DL> When this call fails, you 'assume' netns is not compiled in.
Why is this not an appropriate assumption? If I can't
clone(CLONE_NETNS) for the check, then why should I not assume that
this will fail later when I try to clone() to create the container
itself (despite the presence or absence of netns support)?
Would you argue that testing for basic container support is not
reasonably accomplished by the existing clone() test?
1 - You use a combination of flags to check the network namespace is
implemented. One of the namespaces can fail when trying to create it and
the clone will fail, and you will deduce the network namespace is not
compiled in. But you can do the assumption that never happens.
2 - You try to use only the CLONE_NEWNET flag, and that can fails for
another reasons than it is not implemented. The network namespace
initialization will trigger the initialization of probably more than one
hundred network subsystems which can fail for some reasons. You can
assume that never happens too.
Honestly, these cases are not frequent but they exists. IMO, it is up to
me to warn you when there are some corner cases like these. And it is up
to you to consider you can ignore them because that happens only when we
reach some limits.
If I check for the presence of a kthread, which could go away if the
implementation is changed down the road, then I would falsely conclude
that the feature is not available. This test would fail, even though
I could clone() with the flag and get the proper behavior... Correct?
It is a good point. But I added this kthread because I needed a separate
workq to cleanup the namespace, without this kthread the network
namespace can not work properly.
IMO, it will not be removed very soon :)
But again, you can ignore that, if you prefer to use the 'ip' command.
DL> Who told to scrap the output :) Just verify the return code of
the
DL> command.
You're still scraping the output, just pushing the burden for doing so
onto grep. But, fair enough :)
DL> Anyway, catching a specific return code for an unknown subcommand
DL> makes sense for this check.
Okay, cool.