@yylt: Do you have a use case for this ? I mean, AFAICT this PR tries to add cgroup v1 support for something that we already should support for cgroup v2 using LinuxResources.Unified["pids.max"]. Also, this PR only adds the placeholder for the cgroup v1 max pids setting in the wire protocol. It does not implement doing anything with the actual value if it happens to be set.

We have been trying for a while now to avoid adding anything new cgroup v1-specific bits to NRI.

There are still many distributions, like Rocky Linux 8, kylin linux , and the Rocky Linux 8 uses the 4.18 kernel. Since cgroup v2 recommends a kernel version higher than 5.2, I think it's still necessary to add support for the v1 version of cgroups.

Additional, maybe nri should follow the OCI runtime spec more closely. If the runtime spec doesn't support a specific cgroup, then nri should remove or not add it

There are still many distributions, like Rocky Linux 8, kylin linux , and the Rocky Linux 8 uses the 4.18 kernel. Since cgroup v2 recommends a kernel version higher than 5.2, I think it's still necessary to add support for the v1 version of cgroups.

Additional, maybe nri should follow the OCI runtime spec more closely. If the runtime spec doesn't support a specific cgroup, then nri should remove or not add it

Just adding a note here regarding possibility of v2 to v1 conversions ..

https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#example-12

see example ^ and description: "If a controller is enabled on the cgroup v2 hierarchy but the configuration is provided for the cgroup v1 equivalent controller, the runtime MAY attempt a conversion."

@AkihiroSuda thoughts? Should we be enabling both v1 and v2/unified and exposing the runtime meta at this plugin layer... or push the NRI plugins to cgroupv2 and do any nec. conversions either in CRI/shim or runtime?