generate: fix capability.List() for cap_last_cap not exist

[Mashimiao]

Signed-off-by: masm [email protected]

[wking]

Dup of the just-merged #138?

[Mashimiao]

@wking It seems part of same, but I don't think is a dup.
It's an additional fix for host which does not have cap_last_cap.

[wking]

On Wed, Jul 27, 2016 at 06:13:08PM -0700, Ma Shimiao wrote:

It's an additional fix for host which does not have cap_last_cap.

Ah, I see that with 3334d03 → d326c89 you've put this on top of master
and there's still stuff there ;). Can we collect the hack together
into a:

func LastCap() capability.Cap {
…
}

That way the hack is isolated / DRY. And it would let us add a guard
with Uname 1 or some such if it turns out that we need to fine-tune
your current guessing logic later.

We can probably move those LastCap calls inside the g.HostSpecific
guard as well to make it clear that your system's maximal capability
doesn't matter when g.HostSpecific is false.

[wking]

And all of my above suggestions are for patching around gocapability in ocitools for older kernels. A better fix would be to PR syndtr/gocapability with the additional old-kernel heurstics so you could guess at CAP_LAST_CAP in these cases. These approaches don't have to be mutually exclusive if we want to land the RHEL6 workaround here while we wait for the upstream PR to cook.

[Mashimiao]

@wking already collected all hack together.

[wking]

On Wed, Jul 27, 2016 at 11:11:04PM -0700, Ma Shimiao wrote:

@wking already collected all hack together.

f7df9c7 looks good to me. We can drop the hack if/when something
like this lands in gocapability.

[mrunalp]

LGTM