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

[Daniel Lezcano]

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.