@@ -27,7 +27,7 @@ import (

 	"github.com/moby/sys/mountinfo"

 	"github.com/moby/sys/user"

 	"github.com/moby/sys/userns"

-	"github.com/opencontainers/runc/libcontainer/cgroups"

+	"github.com/opencontainers/cgroups"

 	"github.com/opencontainers/runtime-spec/specs-go"

 	"github.com/pkg/errors"

 )

@@ -80,9 +80,9 @@ require (

 	github.com/moby/sys/userns v0.1.0

 	github.com/moby/term v0.5.2

 	github.com/morikuni/aec v1.0.0

+	github.com/opencontainers/cgroups v0.0.1

 	github.com/opencontainers/go-digest v1.0.0

 	github.com/opencontainers/image-spec v1.1.0

-	github.com/opencontainers/runc v1.2.6

 	github.com/opencontainers/runtime-spec v1.2.0

 	github.com/opencontainers/selinux v1.11.1

 	github.com/pelletier/go-toml v1.9.5

@@ -435,12 +435,12 @@ github.com/onsi/ginkgo/v2 v2.22.0/go.mod h1:7Du3c42kxCUegi0IImZ1wUQzMBVecgIHjR1C

 github.com/onsi/gomega v1.36.0 h1:Pb12RlruUtj4XUuPUqeEWc6j5DkVVVA49Uf6YLfC95Y=

 github.com/onsi/gomega v1.36.0/go.mod h1:PvZbdDc8J6XJEpDK4HCuRBm8a6Fzp9/DmhC9C7yFlog=

 github.com/op/go-logging v0.0.0-20160315200505-970db520ece7/go.mod h1:HzydrMdWErDVzsI23lYNej1Htcns9BCg93Dk0bBINWk=

+github.com/opencontainers/cgroups v0.0.1 h1:MXjMkkFpKv6kpuirUa4USFBas573sSAY082B4CiHEVA=

+github.com/opencontainers/cgroups v0.0.1/go.mod h1:s8lktyhlGUqM7OSRL5P7eAW6Wb+kWPNvt4qvVfzA5vs=

 github.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U=

 github.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM=

 github.com/opencontainers/image-spec v1.1.0 h1:8SG7/vwALn54lVB/0yZ/MMwhFrPYtpEHQb2IpWsCzug=

 github.com/opencontainers/image-spec v1.1.0/go.mod h1:W4s4sFTMaBeK1BQLXbG4AdM2szdn85PY75RI83NrTrM=

-github.com/opencontainers/runc v1.2.6 h1:P7Hqg40bsMvQGCS4S7DJYhUZOISMLJOB2iGX5COWiPk=

-github.com/opencontainers/runc v1.2.6/go.mod h1:dOQeFo29xZKBNeRBI0B19mJtfHv68YgCTh1X+YphA+4=

 github.com/opencontainers/runtime-spec v1.0.3-0.20220825212826-86290f6a00fb/go.mod h1:jwyrGlmzljRJv/Fgzds9SsS/C5hL+LL3ko9hs6T5lQ0=

 github.com/opencontainers/runtime-spec v1.2.0 h1:z97+pHb3uELt/yiAWD691HNHQIF07bE7dzrbT927iTk=

 github.com/opencontainers/runtime-spec v1.2.0/go.mod h1:jwyrGlmzljRJv/Fgzds9SsS/C5hL+LL3ko9hs6T5lQ0=

new file mode 100644

@@ -0,0 +1 @@

+* @maintainer1 @maintainer2 @maintainer3

new file mode 100644

@@ -0,0 +1,150 @@

+# Contribution Guidelines

+

+Development happens on GitHub.

+Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list).

+

+The content of this repository is licensed under the [Apache License, Version 2.0](LICENSE).

+

+## Code of Conduct

+

+Participation in the Open Container community is governed by [Open Container Code of Conduct][code-of-conduct].

+

+## Meetings

+

+The contributors and maintainers of all OCI projects have monthly meetings at 2:00 PM (USA Pacific) on the first Wednesday of every month.

+There is an [iCalendar][rfc5545] format for the meetings [here][meeting.ics].

+Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: +1 415 968 0849 (no PIN needed).

+An initial agenda will be posted to the [mailing list](#mailing-list) in the week before each meeting, and everyone is welcome to propose additional topics or suggest other agenda alterations there.

+Minutes from past meetings are archived [here][minutes].

+

+## Mailing list

+

+You can subscribe and browse the mailing list on [Google Groups][mailing-list].

+

+## IRC

+

+OCI discussion happens on #opencontainers on [Freenode][] ([logs][irc-logs]).

+

+## Git

+

+### Security issues

+

+If you are reporting a security issue, do not create an issue or file a pull

+request on GitHub. Instead, disclose the issue responsibly by sending an email

+to security@opencontainers.org (which is inhabited only by the maintainers of

+the various OCI projects).

+

+### Pull requests are always welcome

+

+We are always thrilled to receive pull requests, and do our best to

+process them as fast as possible. Not sure if that typo is worth a pull

+request? Do it! We will appreciate it.

+

+If your pull request is not accepted on the first try, don't be

+discouraged! If there's a problem with the implementation, hopefully you

+received feedback on what to improve.

+

+We're trying very hard to keep the project lean and focused. We don't want it

+to do everything for everybody. This means that we might decide against

+incorporating a new feature.

+

+### Conventions

+

+Fork the repo and make changes on your fork in a feature branch.

+For larger bugs and enhancements, consider filing a leader issue or mailing-list thread for discussion that is independent of the implementation.

+Small changes or changes that have been discussed on the [project mailing list](#mailing-list) may be submitted without a leader issue.

+

+If the project has a test suite, submit unit tests for your changes. Take a

+look at existing tests for inspiration. Run the full test suite on your branch

+before submitting a pull request.

+

+Update the documentation when creating or modifying features. Test

+your documentation changes for clarity, concision, and correctness, as

+well as a clean documentation build.

+

+Pull requests descriptions should be as clear as possible and include a

+reference to all the issues that they address.

+

+Commit messages must start with a capitalized and short summary

+written in the imperative, followed by an optional, more detailed

+explanatory text which is separated from the summary by an empty line.

+

+Code review comments may be added to your pull request. Discuss, then make the

+suggested modifications and push additional commits to your feature branch. Be

+sure to post a comment after pushing. The new commits will show up in the pull

+request automatically, but the reviewers will not be notified unless you

+comment.

+

+Before the pull request is merged, make sure that you squash your commits into

+logical units of work using `git rebase -i` and `git push -f`. After every

+commit the test suite (if any) should be passing. Include documentation changes

+in the same commit so that a revert would remove all traces of the feature or

+fix.

+

+Commits that fix or close an issue should include a reference like `Closes #XXX`

+or `Fixes #XXX`, which will automatically close the issue when merged.

+

+### Sign your work

+

+The sign-off is a simple line at the end of the explanation for the

+patch, which certifies that you wrote it or otherwise have the right to

+pass it on as an open-source patch.  The rules are pretty simple: if you

+can certify the below (from [developercertificate.org][]):

+

+```

+Developer Certificate of Origin

+Version 1.1

+

+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

+1 Letterman Drive

+Suite D4700

+San Francisco, CA, 94129

+

+Everyone is permitted to copy and distribute verbatim copies of this

+license document, but changing it is not allowed.

+

+

+Developer's Certificate of Origin 1.1

+

+By making a contribution to this project, I certify that:

+

+(a) The contribution was created in whole or in part by me and I

+    have the right to submit it under the open source license

+    indicated in the file; or

+

+(b) The contribution is based upon previous work that, to the best

+    of my knowledge, is covered under an appropriate open source

+    license and I have the right under that license to submit that

+    work with modifications, whether created in whole or in part

+    by me, under the same open source license (unless I am

+    permitted to submit under a different license), as indicated

+    in the file; or

+

+(c) The contribution was provided directly to me by some other

+    person who certified (a), (b) or (c) and I have not modified

+    it.

+

+(d) I understand and agree that this project and the contribution

+    are public and that a record of the contribution (including all

+    personal information I submit with it, including my sign-off) is

+    maintained indefinitely and may be redistributed consistent with

+    this project or the open source license(s) involved.

+```

+

+then you just add a line to every git commit message:

+

+    Signed-off-by: Joe Smith <joe@gmail.com>

+

+using your real name (sorry, no pseudonyms or anonymous contributions.)

+

+You can add the sign off when creating the git commit via `git commit -s`.

+

+[code-of-conduct]: https://github.com/opencontainers/tob/blob/d2f9d68c1332870e40693fe077d311e0742bc73d/code-of-conduct.md

+[developercertificate.org]: http://developercertificate.org/

+[Freenode]: https://freenode.net/

+[irc-logs]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/

+[mailing-list]: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev

+[meeting.ics]: https://github.com/opencontainers/runtime-spec/blob/master/meeting.ics

+[minutes]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/

+[rfc5545]: https://tools.ietf.org/html/rfc5545

+[UberConference]: https://www.uberconference.com/opencontainers

new file mode 100644

@@ -0,0 +1,63 @@

+# Project governance

+

+The [OCI charter][charter] §5.b.viii tasks an OCI Project's maintainers (listed in the repository's MAINTAINERS file and sometimes referred to as "the TDC", [§5.e][charter]) with:

+

+> Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC.

+

+This section describes generic rules and procedures for fulfilling that mandate.

+

+## Proposing a motion

+

+A maintainer SHOULD propose a motion on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor.

+

+## Voting

+

+Voting on a proposed motion SHOULD happen on the dev@opencontainers.org mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT.

+Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote).

+Maintainers MAY post multiple times (e.g. as they revise their position based on feedback), but only their final post counts in the tally.

+A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release.

+

+Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion.

+Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier.

+

+A maintainer MAY choose to reply with REJECT.

+A maintainer posting a REJECT MUST include a list of concerns or links to written documentation for those concerns (e.g. GitHub issues or mailing-list threads).

+The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM.

+However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs.

+

+## Quorum

+

+A quorum is established when at least two-thirds of maintainers have voted.

+

+For projects that are not specifications, a [motion to release](#release-approval) MAY be adopted if the tally is at least three LGTMs and no REJECTs, even if three votes does not meet the usual two-thirds quorum.

+

+## Amendments

+

+The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves.

+The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (go-digest, image-spec, image-tools, runC, runtime-spec, runtime-tools, and selinux).

+

+## Subject templates

+

+Maintainers are busy and get lots of email.

+To make project proposals recognizable, proposed motions SHOULD use the following subject templates.

+

+### Proposing a motion

+

+> [{project} VOTE]: {motion description} (closes {end of voting window})

+

+For example:

+

+> [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC)

+

+### Tallying results

+

+After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like:

+

+> [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs})

+

+Where `{status}` is either `adopted` or `rejected`.

+For example:

+

+> [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3)

+

+[charter]: https://www.opencontainers.org/about/governance

new file mode 100644

@@ -0,0 +1,201 @@

+                                 Apache License

+                           Version 2.0, January 2004

+                        http://www.apache.org/licenses/

+

+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

+

+   1. Definitions.

+

+      "License" shall mean the terms and conditions for use, reproduction,

+      and distribution as defined by Sections 1 through 9 of this document.

+

+      "Licensor" shall mean the copyright owner or entity authorized by

+      the copyright owner that is granting the License.

+

+      "Legal Entity" shall mean the union of the acting entity and all

+      other entities that control, are controlled by, or are under common

+      control with that entity. For the purposes of this definition,

+      "control" means (i) the power, direct or indirect, to cause the

+      direction or management of such entity, whether by contract or

+      otherwise, or (ii) ownership of fifty percent (50%) or more of the

+      outstanding shares, or (iii) beneficial ownership of such entity.

+

+      "You" (or "Your") shall mean an individual or Legal Entity

+      exercising permissions granted by this License.

+

+      "Source" form shall mean the preferred form for making modifications,

+      including but not limited to software source code, documentation

+      source, and configuration files.

+

+      "Object" form shall mean any form resulting from mechanical

+      transformation or translation of a Source form, including but

+      not limited to compiled object code, generated documentation,

+      and conversions to other media types.

+

+      "Work" shall mean the work of authorship, whether in Source or

+      Object form, made available under the License, as indicated by a

+      copyright notice that is included in or attached to the work

+      (an example is provided in the Appendix below).

+

+      "Derivative Works" shall mean any work, whether in Source or Object

+      form, that is based on (or derived from) the Work and for which the

+      editorial revisions, annotations, elaborations, or other modifications

+      represent, as a whole, an original work of authorship. For the purposes

+      of this License, Derivative Works shall not include works that remain

+      separable from, or merely link (or bind by name) to the interfaces of,

+      the Work and Derivative Works thereof.

+

+      "Contribution" shall mean any work of authorship, including

+      the original version of the Work and any modifications or additions

+      to that Work or Derivative Works thereof, that is intentionally

+      submitted to Licensor for inclusion in the Work by the copyright owner

+      or by an individual or Legal Entity authorized to submit on behalf of

+      the copyright owner. For the purposes of this definition, "submitted"

+      means any form of electronic, verbal, or written communication sent

+      to the Licensor or its representatives, including but not limited to

+      communication on electronic mailing lists, source code control systems,

+      and issue tracking systems that are managed by, or on behalf of, the

+      Licensor for the purpose of discussing and improving the Work, but

+      excluding communication that is conspicuously marked or otherwise

+      designated in writing by the copyright owner as "Not a Contribution."

+

+      "Contributor" shall mean Licensor and any individual or Legal Entity

+      on behalf of whom a Contribution has been received by Licensor and

+      subsequently incorporated within the Work.

+

+   2. Grant of Copyright License. Subject to the terms and conditions of

+      this License, each Contributor hereby grants to You a perpetual,

+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable

+      copyright license to reproduce, prepare Derivative Works of,

+      publicly display, publicly perform, sublicense, and distribute the

+      Work and such Derivative Works in Source or Object form.

+

+   3. Grant of Patent License. Subject to the terms and conditions of

+      this License, each Contributor hereby grants to You a perpetual,

+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable

+      (except as stated in this section) patent license to make, have made,

+      use, offer to sell, sell, import, and otherwise transfer the Work,

+      where such license applies only to those patent claims licensable

+      by such Contributor that are necessarily infringed by their

+      Contribution(s) alone or by combination of their Contribution(s)

+      with the Work to which such Contribution(s) was submitted. If You

+      institute patent litigation against any entity (including a

+      cross-claim or counterclaim in a lawsuit) alleging that the Work

+      or a Contribution incorporated within the Work constitutes direct

+      or contributory patent infringement, then any patent licenses

+      granted to You under this License for that Work shall terminate

+      as of the date such litigation is filed.

+

+   4. Redistribution. You may reproduce and distribute copies of the

+      Work or Derivative Works thereof in any medium, with or without

+      modifications, and in Source or Object form, provided that You

+      meet the following conditions:

+

+      (a) You must give any other recipients of the Work or

+          Derivative Works a copy of this License; and

+

+      (b) You must cause any modified files to carry prominent notices

+          stating that You changed the files; and

+

+      (c) You must retain, in the Source form of any Derivative Works

+          that You distribute, all copyright, patent, trademark, and

+          attribution notices from the Source form of the Work,

+          excluding those notices that do not pertain to any part of

+          the Derivative Works; and

+

+      (d) If the Work includes a "NOTICE" text file as part of its

+          distribution, then any Derivative Works that You distribute must

+          include a readable copy of the attribution notices contained

+          within such NOTICE file, excluding those notices that do not

+          pertain to any part of the Derivative Works, in at least one

+          of the following places: within a NOTICE text file distributed

+          as part of the Derivative Works; within the Source form or

+          documentation, if provided along with the Derivative Works; or,

+          within a display generated by the Derivative Works, if and

+          wherever such third-party notices normally appear. The contents

+          of the NOTICE file are for informational purposes only and

+          do not modify the License. You may add Your own attribution

+          notices within Derivative Works that You distribute, alongside

+          or as an addendum to the NOTICE text from the Work, provided

+          that such additional attribution notices cannot be construed

+          as modifying the License.

+

+      You may add Your own copyright statement to Your modifications and

+      may provide additional or different license terms and conditions

+      for use, reproduction, or distribution of Your modifications, or

+      for any such Derivative Works as a whole, provided Your use,

+      reproduction, and distribution of the Work otherwise complies with

+      the conditions stated in this License.

+

+   5. Submission of Contributions. Unless You explicitly state otherwise,

+      any Contribution intentionally submitted for inclusion in the Work

+      by You to the Licensor shall be under the terms and conditions of

+      this License, without any additional terms or conditions.

+      Notwithstanding the above, nothing herein shall supersede or modify

+      the terms of any separate license agreement you may have executed

+      with Licensor regarding such Contributions.

+

+   6. Trademarks. This License does not grant permission to use the trade

+      names, trademarks, service marks, or product names of the Licensor,

+      except as required for reasonable and customary use in describing the

+      origin of the Work and reproducing the content of the NOTICE file.

+

+   7. Disclaimer of Warranty. Unless required by applicable law or

+      agreed to in writing, Licensor provides the Work (and each

+      Contributor provides its Contributions) on an "AS IS" BASIS,

+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or

+      implied, including, without limitation, any warranties or conditions

+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A

+      PARTICULAR PURPOSE. You are solely responsible for determining the

+      appropriateness of using or redistributing the Work and assume any

+      risks associated with Your exercise of permissions under this License.

+

+   8. Limitation of Liability. In no event and under no legal theory,

+      whether in tort (including negligence), contract, or otherwise,

+      unless required by applicable law (such as deliberate and grossly

+      negligent acts) or agreed to in writing, shall any Contributor be

+      liable to You for damages, including any direct, indirect, special,

+      incidental, or consequential damages of any character arising as a

+      result of this License or out of the use or inability to use the

+      Work (including but not limited to damages for loss of goodwill,

+      work stoppage, computer failure or malfunction, or any and all

+      other commercial damages or losses), even if such Contributor

+      has been advised of the possibility of such damages.

+

+   9. Accepting Warranty or Additional Liability. While redistributing

+      the Work or Derivative Works thereof, You may choose to offer,

+      and charge a fee for, acceptance of support, warranty, indemnity,

+      or other liability obligations and/or rights consistent with this

+      License. However, in accepting such obligations, You may act only

+      on Your own behalf and on Your sole responsibility, not on behalf

+      of any other Contributor, and only if You agree to indemnify,

+      defend, and hold each Contributor harmless for any liability

+      incurred by, or claims asserted against, such Contributor by reason

+      of your accepting any such warranty or additional liability.

+

+   END OF TERMS AND CONDITIONS

+

+   APPENDIX: How to apply the Apache License to your work.

+

+      To apply the Apache License to your work, attach the following

+      boilerplate notice, with the fields enclosed by brackets "{}"

+      replaced with your own identifying information. (Don't include

+      the brackets!)  The text should be enclosed in the appropriate

+      comment syntax for the file format. We also recommend that a

+      file or class name and description of purpose be included on the

+      same "printed page" as the copyright notice for easier

+      identification within third-party archives.

+

+   Copyright {yyyy} {name of copyright owner}

+

+   Licensed under the Apache License, Version 2.0 (the "License");

+   you may not use this file except in compliance with the License.

+   You may obtain a copy of the License at

+

+       http://www.apache.org/licenses/LICENSE-2.0

+

+   Unless required by applicable law or agreed to in writing, software

+   distributed under the License is distributed on an "AS IS" BASIS,

+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

+   See the License for the specific language governing permissions and

+   limitations under the License.

new file mode 100644

@@ -0,0 +1,8 @@

+Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp> (@AkihiroSuda)

+Aleksa Sarai <cyphar@cyphar.com> (@cyphar)

+Kir Kolyshkin <kolyshkin@gmail.com> (@kolyshkin)

+Mrunal Patel <mpatel@redhat.com> (@mrunalp)

+Sebastiaan van Stijn <github@gone.nl> (@thaJeztah)

+Odin Ugedal <odin@uged.al> (@odinuge)

+Peter Hunt <pehunt@redhat.com> (@haircommander)

+Davanum Srinivas <davanum@gmail.com> (@dims)

new file mode 100644

@@ -0,0 +1,92 @@

+## Introduction

+

+Dear maintainer. Thank you for investing the time and energy to help

+make this project as useful as possible. Maintaining a project is difficult,

+sometimes unrewarding work.  Sure, you will get to contribute cool

+features to the project. But most of your time will be spent reviewing,

+cleaning up, documenting, answering questions, justifying design

+decisions - while everyone has all the fun! But remember - the quality

+of the maintainers work is what distinguishes the good projects from the

+great.  So please be proud of your work, even the unglamourous parts,

+and encourage a culture of appreciation and respect for *every* aspect

+of improving the project - not just the hot new features.

+

+This document is a manual for maintainers old and new. It explains what

+is expected of maintainers, how they should work, and what tools are

+available to them.

+

+This is a living document - if you see something out of date or missing,

+speak up!

+

+## What are a maintainer's responsibilities?

+

+It is every maintainer's responsibility to:

+

+* Expose a clear roadmap for improving their component.

+* Deliver prompt feedback and decisions on pull requests.

+* Be available to anyone with questions, bug reports, criticism etc. on their component.

+  This includes IRC and GitHub issues and pull requests.

+* Make sure their component respects the philosophy, design and roadmap of the project.

+

+## How are decisions made?

+

+This project is an open-source project with an open design philosophy. This

+means that the repository is the source of truth for EVERY aspect of the

+project, including its philosophy, design, roadmap and APIs. *If it's

+part of the project, it's in the repo. It's in the repo, it's part of

+the project.*

+

+As a result, all decisions can be expressed as changes to the

+repository. An implementation change is a change to the source code. An

+API change is a change to the API specification. A philosophy change is

+a change to the philosophy manifesto. And so on.

+

+All decisions affecting this project, big and small, follow the same procedure:

+

+1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list).

+   Anyone can do this.

+2. Open a pull request.

+   Anyone can do this.

+3. Discuss the pull request.

+   Anyone can do this.

+4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request.

+   The relevant maintainers do this (see below [Who decides what?](#who-decides-what)).

+   Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md).

+5. Merge or close the pull request.

+   The relevant maintainers do this.

+

+### I'm a maintainer, should I make pull requests too?

+

+Yes. Nobody should ever push to master directly. All changes should be

+made through a pull request.

+

+## Who decides what?

+

+All decisions are pull requests, and the relevant maintainers make

+decisions by accepting or refusing the pull request. Review and acceptance

+by anyone is denoted by adding a comment in the pull request: `LGTM`.

+However, only currently listed `MAINTAINERS` are counted towards the required

+two LGTMs. In addition, if a maintainer has created a pull request, they cannot

+count toward the two LGTM rule (to ensure equal amounts of review for every pull

+request, no matter who wrote it).

+

+Overall the maintainer system works because of mutual respect.

+The maintainers trust one another to act in the best interests of the project.

+Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people.

+In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus.

+

+### How are maintainers added?

+

+The best maintainers have a vested interest in the project.  Maintainers

+are first and foremost contributors that have shown they are committed to

+the long term success of the project.  Contributors wanting to become

+maintainers are expected to be deeply involved in contributing code,

+pull request review, and triage of issues in the project for more than two months.

+

+Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on to act in the best interest of the project.

+The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md).

+

+### How are maintainers removed?

+

+When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md).

+Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.

new file mode 100644

@@ -0,0 +1,11 @@

+# OCI Project Template

+

+Useful boilerplate and organizational information for all OCI projects.

+

+* README (this file)

+* [The Apache License, Version 2.0](LICENSE)

+* [A list of maintainers](MAINTAINERS)

+* [Maintainer guidelines](MAINTAINERS_GUIDE.md)

+* [Contributor guidelines](CONTRIBUTING.md)

+* [Project governance](GOVERNANCE.md)

+* [Release procedures](RELEASES.md)

new file mode 100644

@@ -0,0 +1,51 @@

+# Releases

+

+The release process hopes to encourage early, consistent consensus-building during project development.

+The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases.

+Releases are proposed and adopted or rejected using the usual [project governance](GOVERNANCE.md) rules and procedures.

+

+An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases.

+We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.

+

+## Parallel releases

+

+A single project MAY consider several motions to release in parallel.

+However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed.

+

+For example, runtime-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month.

+They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes).

+

+## Specifications

+

+The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools.

+However, specification releases have special restrictions in the [OCI charter][charter]:

+

+* They are the target of backwards compatibility (§7.g), and

+* They are subject to the OFWa patent grant (§8.d and e).

+

+To avoid unfortunate side effects (onerous backwards compatibity requirements or Member resignations), the following additional procedures apply to specification releases:

+

+### Planning a release

+

+Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases.

+This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC.

+Maintainers MUST send updates to the dev@opencontainers.org with results of these meetings.

+

+Before the specification reaches v1.0.0, the meetings SHOULD be weekly.

+Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting.

+

+The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).

+GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures.

+

+### Timelines

+

+Specifications have a variety of different timelines in their lifecycle.

+

+* Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.

+* Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.

+  This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.

+  Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.

+  For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.

+* Minor and patch releases SHOULD be made on an as-needed basis.

+

+[charter]: https://www.opencontainers.org/about/governance

new file mode 100644

@@ -0,0 +1,78 @@

+package cgroups

+

+import (

+	"errors"

+)

+

+var (

+	// ErrDevicesUnsupported is an error returned when a cgroup manager

+	// is not configured to set device rules.

+	ErrDevicesUnsupported = errors.New("cgroup manager is not configured to set device rules")

+

+	// ErrRootless is returned by [Manager.Apply] when there is an error

+	// creating cgroup directory, and cgroup.Rootless is set. In general,

+	// this error is to be ignored.

+	ErrRootless = errors.New("cgroup manager can not access cgroup (rootless container)")

+

+	// DevicesSetV1 and DevicesSetV2 are functions to set devices for

+	// cgroup v1 and v2, respectively. Unless

+	// [github.com/opencontainers/cgroups/devices]

+	// package is imported, it is set to nil, so cgroup managers can't

+	// manage devices.

+	DevicesSetV1 func(path string, r *Resources) error

+	DevicesSetV2 func(path string, r *Resources) error

+)

+

+type Manager interface {

+	// Apply creates a cgroup, if not yet created, and adds a process

+	// with the specified pid into that cgroup.  A special value of -1

+	// can be used to merely create a cgroup.

+	Apply(pid int) error

+

+	// GetPids returns the PIDs of all processes inside the cgroup.

+	GetPids() ([]int, error)

+

+	// GetAllPids returns the PIDs of all processes inside the cgroup

+	// any all its sub-cgroups.

+	GetAllPids() ([]int, error)

+

+	// GetStats returns cgroups statistics.

+	GetStats() (*Stats, error)

+

+	// Freeze sets the freezer cgroup to the specified state.

+	Freeze(state FreezerState) error

+

+	// Destroy removes cgroup.

+	Destroy() error

+

+	// Path returns a cgroup path to the specified controller/subsystem.

+	// For cgroupv2, the argument is unused and can be empty.

+	Path(string) string

+

+	// Set sets cgroup resources parameters/limits. If the argument is nil,

+	// the resources specified during Manager creation (or the previous call

+	// to Set) are used.

+	Set(r *Resources) error

+

+	// GetPaths returns cgroup path(s) to save in a state file in order to

+	// restore later.

+	//

+	// For cgroup v1, a key is cgroup subsystem name, and the value is the

+	// path to the cgroup for this subsystem.

+	//

+	// For cgroup v2 unified hierarchy, a key is "", and the value is the

+	// unified path.

+	GetPaths() map[string]string

+

+	// GetCgroups returns the cgroup data as configured.

+	GetCgroups() (*Cgroup, error)

+

+	// GetFreezerState retrieves the current FreezerState of the cgroup.

+	GetFreezerState() (FreezerState, error)

+

+	// Exists returns whether the cgroup path exists or not.

+	Exists() bool

+

+	// OOMKillCount reports OOM kill count for the cgroup.

+	OOMKillCount() (uint64, error)

+}

new file mode 100644

@@ -0,0 +1,66 @@

+package cgroups

+

+import "fmt"

+

+// BlockIODevice holds major:minor format supported in blkio cgroup.

+type BlockIODevice struct {

+	// Major is the device's major number

+	Major int64 `json:"major"`

+	// Minor is the device's minor number

+	Minor int64 `json:"minor"`

+}

+

+// WeightDevice struct holds a `major:minor weight`|`major:minor leaf_weight` pair

+type WeightDevice struct {

+	BlockIODevice

+	// Weight is the bandwidth rate for the device, range is from 10 to 1000

+	Weight uint16 `json:"weight"`

+	// LeafWeight is the bandwidth rate for the device while competing with the cgroup's child cgroups, range is from 10 to 1000, cfq scheduler only

+	LeafWeight uint16 `json:"leafWeight"`

+}

+

+// NewWeightDevice returns a configured WeightDevice pointer

+func NewWeightDevice(major, minor int64, weight, leafWeight uint16) *WeightDevice {

+	wd := &WeightDevice{}

+	wd.Major = major

+	wd.Minor = minor

+	wd.Weight = weight

+	wd.LeafWeight = leafWeight

+	return wd

+}

+

+// WeightString formats the struct to be writable to the cgroup specific file

+func (wd *WeightDevice) WeightString() string {

+	return fmt.Sprintf("%d:%d %d", wd.Major, wd.Minor, wd.Weight)

+}

+

+// LeafWeightString formats the struct to be writable to the cgroup specific file

+func (wd *WeightDevice) LeafWeightString() string {

+	return fmt.Sprintf("%d:%d %d", wd.Major, wd.Minor, wd.LeafWeight)

+}

+

+// ThrottleDevice struct holds a `major:minor rate_per_second` pair

+type ThrottleDevice struct {

+	BlockIODevice

+	// Rate is the IO rate limit per cgroup per device

+	Rate uint64 `json:"rate"`

+}

+

+// NewThrottleDevice returns a configured ThrottleDevice pointer

+func NewThrottleDevice(major, minor int64, rate uint64) *ThrottleDevice {

+	td := &ThrottleDevice{}

+	td.Major = major

+	td.Minor = minor

+	td.Rate = rate

+	return td

+}

+

+// String formats the struct to be writable to the cgroup specific file

+func (td *ThrottleDevice) String() string {

+	return fmt.Sprintf("%d:%d %d", td.Major, td.Minor, td.Rate)

+}

+

+// StringName formats the struct to be writable to the cgroup specific file

+func (td *ThrottleDevice) StringName(name string) string {

+	return fmt.Sprintf("%d:%d %s=%d", td.Major, td.Minor, name, td.Rate)

+}

new file mode 100644

@@ -0,0 +1,9 @@

+package cgroups

+

+type HugepageLimit struct {

+	// which type of hugepage to limit.

+	Pagesize string `json:"page_size"`

+

+	// usage limit for hugepage.

+	Limit uint64 `json:"limit"`

+}

new file mode 100644

@@ -0,0 +1,14 @@

+package cgroups

+

+import (

+	"fmt"

+)

+

+type IfPrioMap struct {

+	Interface string `json:"interface"`

+	Priority  int64  `json:"priority"`

+}

+

+func (i *IfPrioMap) CgroupString() string {

+	return fmt.Sprintf("%s %d", i.Interface, i.Priority)

+}

new file mode 100644

@@ -0,0 +1,169 @@

+package cgroups

+

+import (

+	systemdDbus "github.com/coreos/go-systemd/v22/dbus"

+	devices "github.com/opencontainers/cgroups/devices/config"

+)

+

+type FreezerState string

+

+const (

+	Undefined FreezerState = ""

+	Frozen    FreezerState = "FROZEN"

+	Thawed    FreezerState = "THAWED"

+)

+

+// Cgroup holds properties of a cgroup on Linux.

+type Cgroup struct {

+	// Name specifies the name of the cgroup

+	Name string `json:"name,omitempty"`

+

+	// Parent specifies the name of parent of cgroup or slice

+	Parent string `json:"parent,omitempty"`

+

+	// Path specifies the path to cgroups that are created and/or joined by the container.

+	// The path is assumed to be relative to the host system cgroup mountpoint.

+	Path string `json:"path"`

+

+	// ScopePrefix describes prefix for the scope name

+	ScopePrefix string `json:"scope_prefix"`

+

+	// Resources contains various cgroups settings to apply

+	*Resources

+

+	// Systemd tells if systemd should be used to manage cgroups.

+	Systemd bool

+