Dan Smith wrote:
DL> You call DL> clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET)
DL> When this call fails, you 'assume' netns is not compiled in.
No, actually, I do this:
int flags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER| CLONE_NEWIPC|SIGCHLD|extra_flags;
Where extra_flags=0 for the LXC detection and extra_flags=CLONE_NEWNET for the NETNS detection. See the lxcCheckContainerSupport() calls in lxcProbe() and lxcCheckNetNsSupport().
lxcCheckContainerSupport(0) => clone(CLONE_NEWPID| CLONE_NEWNS| CLONE_NEWUTS| CLONE_NEWUSER| CLONE_NEWIPC| SIGCHLD); lxcCheckNetNsSupport() => lxcCheckContainerSupport(CLONE_NEWNET) => clone(CLONE_NEWPID| CLONE_NEWNS| CLONE_NEWUTS| CLONE_NEWUSER| CLONE_NEWIPC| SIGCHLD|CLONE_NEWNET); Did I missed something ?
DL> In your code, you launch the ip command and if it fails with a DL> particular exit code, you 'assume' netns is not supported. Another DL> assumption
The ip command returns a different error code for an invalid subcommand than for a failure of a known subcommand. That seems like a pretty reasonable sentinel (and certainly better than scraping the help output), IMHO.
Who told to scrap the output :) Just verify the return code of the command. Anyway, catching a specific return code for an unknown subcommand makes sense for this check.
DL> ... IMHO you should rely on the package dependencies/command DL> version. Or if you absolutely want to detect that at startup, DL> perhaps doing "ip link help | grep netns" is more secure :)
DV has already said he'd like to see it done dynamically at the driver probe stage. I'll let him comment on his preferred way of doing that.