libcontainer: configs: ensure can build on darwin

[egernst]

configs package can no longer be built on non-Linux OS, such as Darwin.

When running GOOS=darwin go build on the packge, we had the following
errors:

./configs/mount.go:34:16: undefined: unix.MountAttr
./configs/mount.go:47:22: undefined: unix.MS_BIND

Let's ensure that the linux specific bits are handled in mount_linux.go,
and introduce a _unsupported file, similar to how cgroups file is
handled within the package. This'll facilitate utilization of the pkg
for other projects that care about Darwin.

Signed-off-by: Eric Ernst eric_ernst@apple.com

[egernst]

AFAICT, these CI failures aren't introduced by my change. noop PR also failing: #3698

[egernst]

/cc @AkihiroSuda, @alban @rata

[rata]

It would be great if you can paste the compilation error you see (not all the lines, just the important ones if it is too verbose), so we can easily know how this fails and why this fixes it.

With the info you posted (here and in the issue) is hard to know if some changes are needed (posted those inline).

Also, why do you need this to compile on Mac? I mean, none of the cgroup stuff works there, right? Is it even a supported platform for runc?

I'm fine with the PR, but if we don't want to regress, we should probably add a test to compile on Mac, that I'm not sure what maintainers think about that.

[egernst]

It would be great if you can paste the compilation error you see (not all the lines, just the important ones if it is too verbose), so we can easily know how this fails and why this fixes it.

Good call - updated the PR description

Also, why do you need this to compile on Mac? I mean, none of the cgroup stuff works there, right? Is it even a supported platform for runc?

Libcontainer configs is utilized in other projects, including Kata Containers, which is adding support for building and running on Darwin.

I'm fine with the PR, but if we don't want to regress, we should probably add a test to compile on Mac, that I'm not sure what maintainers think about that.

Sure - you don't need to be on Mac. Just run "GOOS=darwin go build".

[rata]

Also, why do you need this to compile on Mac? I mean, none of the cgroup stuff works there, right? Is it even a supported platform for runc?

Libcontainer configs is utilized in other projects, including Kata Containers, which is adding support for building and running on Darwin.

Ohh, seems reasonable. Can you add that to the PR description and commit message?

I'm fine with the PR, but if we don't want to regress, we should probably add a test to compile on Mac, that I'm not sure what maintainers think about that.

Sure - you don't need to be on Mac. Just run "GOOS=darwin go build".

Right, thanks! :)

[egernst]

Updated the commit/PR to add more detail, and made the changes to dedup the struct based on your feedback. Thanks Rodrigo!

[rata]

LGTM, thanks!

[rata]

LGTM

[rata]

Ups, the linter seems very unhappy about this change. Can you fix it? :)

[egernst]

Ouch, this deals less with lint, and more with compilation failure. My bad.

The issue is not being able to directly compose a struct that has an embedded struct (see golang/go#9859). As an example, we cannot directly initialize the embedded structs fields:

			m := &configs.Mount{Destination: node.Path, Source: node.Path}

This results in the Field Destination doesn't exist. We would need to do something like:

			m := &configs.Mount{}
			m.Destination = node.Path
			m.Source = node.Path

I don't love the making that change throughout the code - the UX in Golang for this is quite lacking.

Curious to hear feedback on how you think it'd make sense to proceed here (ie, dup the struct or make changes in code base to expose the embedded struct).

For me, I think just duplicating those fields, while not ideal, makes more sense. Pushing a commit to remove the embedded struct for your feedback.

[dcantah]

LGTM

[rata]

LGTM, thanks!