chore: run mdformat

This commit was created by running `mdformat .` in the repository root.

Signed-off-by: Patrick Roy <[email protected]>

Author: roypat

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,10 +1,9 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: "[Bug] Title"
+title: '[Bug] Title'
 labels: 'Quality: Bug'
 assignees: ''
-
 ---
 
 # Describe the bug
@@ -14,8 +13,7 @@ assignees: ''
 ## To Reproduce
 
 `[Author TODO: Steps to reproduce the behaviour:]`
-`[ 1. Start Firecracker via....]`
-`[ 2. Configure Firecracker via....]`
+`[ 1. Start Firecracker via....]` `[ 2. Configure Firecracker via....]`
 `[ 3. ....]`
 
 ## Expected behaviour
@@ -25,10 +23,8 @@ assignees: ''
 ## Environment
 
 `[Author TODO: Please supply the following information):]`
-`[ - Firecracker version.]`
-`[ - Host and guest kernel versions.]`
-`[ - Rootfs used.]`
-`[ - Architecture.]`
+`[ - Firecracker version.]` `[ - Host and guest kernel versions.]`
+`[ - Rootfs used.]` `[ - Architecture.]`
 `[ - Any other relevant software versions.]`
 
 ## Additional context

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,26 +1,22 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: "[Feature Request] Title"
+title: '[Feature Request] Title'
 labels: ''
 assignees: ''
-
 ---
 
 # Feature Request
 
-`[Author TODO: Why is this feature request important? What are the use cases?
-Please describe.]`
+`[Author TODO: Why is this feature request important? What are the use cases? Please describe.]`
 
 ## Describe the desired solution
 
-`[Author TODO: A clear and concise description of how you would like
-the feature to work.]`
+`[Author TODO: A clear and concise description of how you would like the feature to work.]`
 
 ## Describe possible alternatives
 
-`[Author TODO: A clear and concise description of any alternative solutions
-or features you have considered.]`
+`[Author TODO: A clear and concise description of any alternative solutions or features you have considered.]`
 
 `[Author TODO: How do you work around not having this feature?]`
 

.github/pull_request_template.md

@@ -9,22 +9,24 @@
 ## License Acceptance
 
 By submitting this pull request, I confirm that my contribution is made under
-the terms of the Apache 2.0 license. For more information on following
-Developer Certificate of Origin and signing off your commits, please check
+the terms of the Apache 2.0 license. For more information on following Developer
+Certificate of Origin and signing off your commits, please check
 [`CONTRIBUTING.md`][3].
 
 ## PR Checklist
 
 - [ ] If a specific issue led to this PR, this PR closes the issue.
 - [ ] The description of changes is clear and encompassing.
-- [ ] Any required documentation changes (code and docs) are included in this PR.
+- [ ] Any required documentation changes (code and docs) are included in this
+  PR.
 - [ ] API changes follow the [Runbook for Firecracker API changes][2].
 - [ ] User-facing changes are mentioned in `CHANGELOG.md`.
 - [ ] All added/changed functionality is tested.
 - [ ] New `TODO`s link to an issue.
-- [ ] Commits meet [contribution quality standards](https://github.com/firecracker-microvm/firecracker/blob/main/CONTRIBUTING.md#contribution-quality-standards).
+- [ ] Commits meet
+  [contribution quality standards](https://github.com/firecracker-microvm/firecracker/blob/main/CONTRIBUTING.md#contribution-quality-standards).
 
----
+______________________________________________________________________
 
 - [ ] This functionality cannot be added in [`rust-vmm`][1].
 

CHANGELOG.md

@@ -2,35 +2,33 @@
 
 ## Mission
 
-Our mission is to enable secure, multi-tenant, minimal-overhead
-execution of container and function workloads.
+Our mission is to enable secure, multi-tenant, minimal-overhead execution of
+container and function workloads.
 
 ## Tenets (unless you know better ones)
 
 These tenets guide Firecracker's development:
 
-1. **Built-In Security**: We provide compute security barriers that
-   enable multi-tenant workloads, and cannot be mistakenly disabled by
-   customers. Customer workloads are simultaneously considered sacred
-   (shall not be touched) and malicious (shall be defended against).
-   We continuously invest in defense in depth and maintain mechanisms
-   that ensure security best practices.
-1. **Light-Weight Virtualization**: We prioritize measuring
-   Firecracker's hardware overhead in the dimensions that are important
-   for our customers, and we strive to make this overhead negligible.
-1. **Minimalist in Features**: If it's not clearly required for our
-   mission, we won't build it. We maintain a single implementation per
-   capability, and deprecate obsolete implementations; resolving
-   exceptions is a high priority issue.
-1. **Compute Oversubscription**: All of the hardware compute resources
-   exposed by Firecracker to guests can be securely oversubscribed.
+1. **Built-In Security**: We provide compute security barriers that enable
+   multi-tenant workloads, and cannot be mistakenly disabled by customers.
+   Customer workloads are simultaneously considered sacred (shall not be
+   touched) and malicious (shall be defended against). We continuously invest in
+   defense in depth and maintain mechanisms that ensure security best practices.
+1. **Light-Weight Virtualization**: We prioritize measuring Firecracker's
+   hardware overhead in the dimensions that are important for our customers, and
+   we strive to make this overhead negligible.
+1. **Minimalist in Features**: If it's not clearly required for our mission, we
+   won't build it. We maintain a single implementation per capability, and
+   deprecate obsolete implementations; resolving exceptions is a high priority
+   issue.
+1. **Compute Oversubscription**: All of the hardware compute resources exposed
+   by Firecracker to guests can be securely oversubscribed.
 
 ## Contributions & Project Roles
 
 All contributions must align with this charter and follow Firecracker's
 [contribution process](CONTRIBUTING.md).
 
-Firecracker [maintainers](MAINTAINERS.md) merge contributions into the
-main branch and create Firecracker releases. Maintainers are also
-subject to the mission and tenets outlined above. Anyone may submit
-and review contributions.
+Firecracker [maintainers](MAINTAINERS.md) merge contributions into the main
+branch and create Firecracker releases. Maintainers are also subject to the
+mission and tenets outlined above. Anyone may submit and review contributions.

CHARTER.md

@@ -1,8 +1,8 @@
 # Code of Conduct
 
 This project has adopted the
-[Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct).
-For more information see the
+[Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct). For
+more information see the
 [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact
 [[email protected]](mailto:[email protected])
 with any additional questions or comments.

CODE_OF_CONDUCT.md

@@ -33,9 +33,9 @@ you want to merge your changes to Firecracker:
 1. Add two reviewers to your pull request (a maintainer will do that for you if
    you're new). Work with your reviewers to address any comments and obtain a
    minimum of 2 approvals, at least one of which must be provided by
-   [a maintainer](MAINTAINERS.md).
-   To update your pull request amend existing commits whenever applicable and
-   then push the new changes to your pull request branch.
+   [a maintainer](MAINTAINERS.md). To update your pull request amend existing
+   commits whenever applicable and then push the new changes to your pull
+   request branch.
 1. Once the pull request is approved, one of the maintainers will merge it.
 
 ## Request for Comments
@@ -68,14 +68,20 @@ rusty-hook init
 Your contribution needs to meet the following standards:
 
 - Separate each **logical change** into its own commit.
+
 - Each commit must pass all unit & code style tests, and the full pull request
   must pass all integration tests. See [tests/README.md](tests/README.md) for
   information on how to run tests.
+
 - Unit test coverage must _increase_ the overall project code coverage.
+
 - Include integration tests for any new functionality in your pull request.
+
 - Document all your public functions.
+
 - Add a descriptive message for each commit. Follow
   [commit message best practices](https://github.com/erlang/otp/wiki/writing-good-commit-messages).
+
 - A good commit message may look like
 
   ```
@@ -87,19 +93,19 @@ Your contribution needs to meet the following standards:
   Co-authored-by: <B full name> <B email>
   ```
 
-- **Usage of `unsafe` is heavily discouraged**. If `unsafe` is required,
-  it should be accompanied by a comment detailing its...
+- **Usage of `unsafe` is heavily discouraged**. If `unsafe` is required, it
+  should be accompanied by a comment detailing its...
+
   - Justification, potentially including quantifiable reasons why safe
     alternatives were not used (e.g. via a benchmark showing a valuable[^1]
     performance improvements).
-  - Safety, as per [`clippy::undocumented_unsafe_blocks`](https://rust-lang.github.io/rust-clippy/master/#undocumented_unsafe_blocks).
-    This comment must list all invariants of the called function, and
-    explain why there are upheld. If relevant, it must also prove that
+  - Safety, as per
+    [`clippy::undocumented_unsafe_blocks`](https://rust-lang.github.io/rust-clippy/master/#undocumented_unsafe_blocks).
+    This comment must list all invariants of the called function, and explain
+    why there are upheld. If relevant, it must also prove that
     [undefined behavior](https://doc.rust-lang.org/reference/behavior-considered-undefined.html)
     is not possible.
 
-  [^1]: Performance improvements in non-hot paths are unlikely to be considered valuable.
-
   E.g.
 
   ```rust
@@ -113,24 +119,26 @@ Your contribution needs to meet the following standards:
   }
   ```
 
-- Document your pull requests. Include the reasoning behind each change, and
-  the testing done.
+- Document your pull requests. Include the reasoning behind each change, and the
+  testing done.
+
 - Acknowledge Firecracker's [Apache 2.0 license](LICENSE) and certify that no
   part of your contribution contravenes this license by signing off on all your
   commits with `git -s`. Ensure that every file in your pull request has a
   header referring to the repository license file.
 
 ## Developer Certificate of Origin
 
-Firecracker is an open source product released under the [Apache 2.0 license](LICENSE).
+Firecracker is an open source product released under the
+[Apache 2.0 license](LICENSE).
 
 We respect intellectual property rights of others and we want to make sure all
-incoming contributions are correctly attributed and licensed.
-A Developer Certificate of Origin (DCO) is a lightweight mechanism to do that.
+incoming contributions are correctly attributed and licensed. A Developer
+Certificate of Origin (DCO) is a lightweight mechanism to do that.
 
-The DCO is a declaration attached to every contribution made by every
-developer. In the commit message of the contribution, the developer simply adds
-a `Signed-off-by` statement and thereby agrees to the DCO, which you can find
+The DCO is a declaration attached to every contribution made by every developer.
+In the commit message of the contribution, the developer simply adds a
+`Signed-off-by` statement and thereby agrees to the DCO, which you can find
 below or at DeveloperCertificate.org (<http://developercertificate.org/>).
 
 ```
@@ -167,16 +175,19 @@ Certificate of Origin. DCO checks are enabled via <https://github.com/apps/dco>,
 and your PR will fail CI without it.
 
 Additionally, we kindly ask you to use your real name. We do not accept
-anonymous contributors, nor those utilizing pseudonyms.
-Each commit must include a DCO which looks like this:
+anonymous contributors, nor those utilizing pseudonyms. Each commit must include
+a DCO which looks like this:
 
 ```
 Signed-off-by: Jane Smith <[email protected]>
 ```
 
-You may type this line on your own when writing your commit messages.
-However, if your `user.name` and `user.email` are set in your git config,
-you can use `-s` or `--signoff` to add the `Signed-off-by` line to the end of
-the commit message automatically.
+You may type this line on your own when writing your commit messages. However,
+if your `user.name` and `user.email` are set in your git config, you can use
+`-s` or `--signoff` to add the `Signed-off-by` line to the end of the commit
+message automatically.
 
 Forgot to add DCO to a commit? Amend it with `git commit --amend -s`.
+
+[^1]: Performance improvements in non-hot paths are unlikely to be considered
+    valuable.