[libvirt] [PATCH 1 of 4] [LXC] Detect support for NETNS in lxc driver initialization

[Daniel Lezcano]

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.