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? 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? 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. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx
Attachment:
pgpdMOm2n8cY0.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list