[libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization
dlezcano at fr.ibm.com
Wed Jun 25 21:44:30 UTC 2008
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.
More information about the libvir-list