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.
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list