chore: apply updated mdformat styles

It seemingly finally got intelligent enough to realize we don't need all
these backslashes on the brackets.

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

Author: roypat

CHANGELOG.md

@@ -60,11 +60,10 @@ minimal required device model to the guest operating system while excluding
 non-essential functionality (only 6 emulated devices are available: virtio-net,
 virtio-balloon, virtio-block, virtio-vsock, serial console, and a minimal
 keyboard controller used only to stop the microVM). This, along with a
-streamlined kernel loading process enables a \< 125 ms startup time and a \< 5
-MiB memory footprint. The Firecracker process also provides a RESTful control
-API, handles resource rate limiting for microVMs, and provides a microVM
-metadata service to enable the sharing of configuration data between the host
-and guest.
+streamlined kernel loading process enables a < 125 ms startup time and a < 5 MiB
+memory footprint. The Firecracker process also provides a RESTful control API,
+handles resource rate limiting for microVMs, and provides a microVM metadata
+service to enable the sharing of configuration data between the host and guest.
 
 ### What operating systems are supported by Firecracker?
 

FAQ.md

@@ -116,7 +116,7 @@ The **API endpoint** can be used to:
 - Add a [entropy device](docs/entropy.md) to the microVM.
 - Start the microVM using a given kernel image, root file system, and boot
   arguments.
-- \[x86_64 only\] Stop the microVM.
+- [x86_64 only] Stop the microVM.
 
 **Built-in Capabilities**:
 
@@ -130,14 +130,14 @@ The **API endpoint** can be used to:
 
 We test all combinations of:
 
-| Instance  | Host OS & Kernel  | Guest Rootfs | Guest Kernel |
-| :-------- | :---------------- | :----------- | :----------- |
-| c5n.metal | al2    linux_5.10 | ubuntu 24.04 | linux_5.10   |
-| m5n.metal | al2023 linux_6.1  |              | linux_6.1    |
-| m6i.metal |                   |              |              |
-| m6a.metal |                   |              |              |
-| m6g.metal |                   |              |              |
-| m7g.metal |                   |              |              |
+| Instance  | Host OS & Kernel | Guest Rootfs | Guest Kernel |
+| :-------- | :--------------- | :----------- | :----------- |
+| c5n.metal | al2 linux_5.10   | ubuntu 24.04 | linux_5.10   |
+| m5n.metal | al2023 linux_6.1 |              | linux_6.1    |
+| m6i.metal |                  |              |              |
+| m6a.metal |                  |              |              |
+| m6g.metal |                  |              |              |
+| m7g.metal |                  |              |              |
 
 ## Known issues and Limitations
 

README.md

@@ -31,7 +31,7 @@ curl --unix-socket /tmp/firecracker.socket -i \
     -d '{ "action_type": "FlushMetrics" }'
 ```
 
-## \[Intel and AMD only\] SendCtrlAltDel
+## [Intel and AMD only] SendCtrlAltDel
 
 This action will send the CTRL+ALT+DEL key sequence to the microVM. By
 convention, this sequence has been used to trigger a soft reboot and, as such,

docs/api_requests/actions.md

@@ -6,7 +6,7 @@ system calls.
 
 Firecracker 1.0.0 adds support for an asynchronous block device IO engine.
 
-> \[!WARNING\]
+> [!WARNING]
 >
 > Support is currently in **developer preview**. See
 > [this section](#developer-preview-status) for more info.

docs/api_requests/block-io-engine.md

@@ -1,6 +1,6 @@
 # Vhost-user block device
 
-> \[!WARNING\]
+> [!WARNING]
 >
 > Support is currently in **developer preview**. See
 > [this section](../RELEASE_POLICY.md#developer-preview-features) for more info.

docs/api_requests/block-vhost-user.md

@@ -143,45 +143,40 @@ Verification Time: 0.19135727s
 ## FAQ
 
 **Q:** What is the Kani verifier?\
-**A:** The
-[Kani Rust Verifier](https://github.com/model-checking/kani) is a bit-precise
-model checker for Rust. Kani is particularly useful for verifying unsafe code
-blocks in Rust, where the
+**A:** The [Kani Rust Verifier](https://github.com/model-checking/kani) is a
+bit-precise model checker for Rust. Kani is particularly useful for verifying
+unsafe code blocks in Rust, where the
 “[unsafe superpowers](https://doc.rust-lang.org/stable/book/ch19-01-unsafe-rust.html#unsafe-superpowers)"
 are unchecked by the compiler.
 
 **Q:** What safety properties does Kani verify?\
-**A:** Kani verifies memory
-safety properties (e.g., invalid-pointer dereferences, out-of-bounds array
-access), user-specified assertions (i.e., `assert!(...)`), the absence of
-`panic!()`s (e.g., `unwrap()` on `None` values), and the absence of some types
-of unexpected behavior (e.g., arithmetic overflows). For a full overview, see
-the
+**A:** Kani verifies memory safety properties (e.g., invalid-pointer
+dereferences, out-of-bounds array access), user-specified assertions (i.e.,
+`assert!(...)`), the absence of `panic!()`s (e.g., `unwrap()` on `None` values),
+and the absence of some types of unexpected behavior (e.g., arithmetic
+overflows). For a full overview, see the
 [Kani documentation](https://model-checking.github.io/kani/tutorial-kinds-of-failure.html).
 
 **Q:** Do we expect all contributors to write harnesses for newly introduced
 code?\
-**A:** No. Kani is complementary to unit testing, and we do not have
-target for “proof coverage”. We employ formal verification in especially
-critical code areas. Generally we do not expect someone who might not be
-familiar with formal tools to contribute harnesses. We do expect all contributed
-code to pass verification though, just like we expect it to pass unit test!
+**A:** No. Kani is complementary to unit testing, and we do not have target for
+“proof coverage”. We employ formal verification in especially critical code
+areas. Generally we do not expect someone who might not be familiar with formal
+tools to contribute harnesses. We do expect all contributed code to pass
+verification though, just like we expect it to pass unit test!
 
 **Q:** How should I report issues related to any Firecracker harnesses?\
-**A:**
-Our Kani harnesses verify safety critical invariants. If you discover a flaw in
-a harness, please report it using the
+**A:** Our Kani harnesses verify safety critical invariants. If you discover a
+flaw in a harness, please report it using the
 [security issue disclosure process](https://github.com/firecracker-microvm/firecracker/blob/main/SECURITY.md).
 
-**Q:** How do I know which properties I should prove in the Kani
-harness?\
-**A:** Generally, these are given by some sort of specification. This
-can either be the function contract described in its document (e.g. what
-relation between input and output do callers expect?), or even something formal
-such as the TCP/IP standard. Don't forget to mention the specification in your
-proof harness!
+**Q:** How do I know which properties I should prove in the Kani harness?\
+**A:** Generally, these are given by some sort of specification. This can either
+be the function contract described in its document (e.g. what relation between
+input and output do callers expect?), or even something formal such as the
+TCP/IP standard. Don't forget to mention the specification in your proof
+harness!
 
 **Q:** Where do I debug a broken proof?\
-**A:** Check out the Kani book section
-on
+**A:** Check out the Kani book section on
 [debugging verification failures](https://model-checking.github.io/kani/debugging-verification-failures.html).

docs/formal-verification.md

@@ -1,6 +1,6 @@
 # Backing Guest Memory by Huge Pages
 
-> \[!WARNING\]
+> [!WARNING]
 >
 > Support is currently in **developer preview**. See
 > [this section](RELEASE_POLICY.md#developer-preview-features) for more info.

docs/hugepages.md

@@ -254,18 +254,18 @@ echo "swap partitions present (Recommendation: no swap)" \
 
 ### Mitigating hardware vulnerabilities
 
-> \[!CAUTION\]
+> [!CAUTION]
 >
 > Firecracker is not able to mitigate host's hardware vulnerabilities. Adequate
 > mitigations need to be put in place when configuring the host.
 
-> \[!CAUTION\]
+> [!CAUTION]
 >
 > Firecracker is designed to provide isolation boundaries between microVMs
 > running in different Firecracker processes. It is strongly recommended that
 > each Firecracker process corresponds to a workload of a single tenant.
 
-> \[!CAUTION\]
+> [!CAUTION]
 >
 > For security and stability reasons it is highly recommended to load updated
 > microcode as soon as possible. Aside from keeping the system firmware
@@ -328,7 +328,7 @@ For vendor-specific recommendations, please consult the resources below:
 - ARM:
   [Speculative Processor Vulnerability](https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability)
 
-##### \[ARM only\] Physical counter directly passed through to the guest
+##### [ARM only] Physical counter directly passed through to the guest
 
 On ARM, the physical counter (i.e `CNTPCT`) it is returning the
 [actual EL1 physical counter value of the host][1]. From the discussions before

docs/prod-host-setup.md

@@ -3,7 +3,7 @@
 This document presents a strategy to ensure continued network connectivity for
 multiple clones created from a single Firecracker microVM snapshot.
 
-> \[!CAUTION\]
+> [!CAUTION]
 >
 > This should be considered as just an example to get you started, and we don't
 > claim this is a performant or secure setup.

docs/snapshotting/network-for-clones.md

@@ -37,7 +37,7 @@ workload at that particular point in time.
 
 ### Supported platforms
 
-> \[!WARNING\]
+> [!WARNING]
 >
 > The Firecracker snapshot feature is in
 > [developer preview](../RELEASE_POLICY.md) on all CPU micro-architectures

docs/snapshotting/snapshot-support.md

@@ -400,36 +400,33 @@ setting to achieve consistent performance. Please see the `test` section of
 
 `Q1:` *I have a shell script that runs my tests and I don't want to rewrite
 it.*\
-`A1:` Insofar as it makes sense, you should write it as a python test
-function. However, you can always call the script from a shim python test
-function. You can also add it as a microvm image resource in the s3 bucket (and
-it will be made available under `microvm.slot.path`) or copy it over to a guest
-filesystem as part of your test.
+`A1:` Insofar as it makes sense, you should write it as a python test function.
+However, you can always call the script from a shim python test function. You
+can also add it as a microvm image resource in the s3 bucket (and it will be
+made available under `microvm.slot.path`) or copy it over to a guest filesystem
+as part of your test.
 
 `Q2:` *I want to add more tests that I don't want to commit to the Firecracker
 repository.*\
-`A2:` Before a testrun or test session, just add your test
-directory under `tests/`. `pytest` will discover all tests in this tree.
+`A2:` Before a testrun or test session, just add your test directory under
+`tests/`. `pytest` will discover all tests in this tree.
 
-`Q3:` *I want to have my own test fixtures, and not commit them in the
-repo.*\
-`A3:` Add a `conftest.py` file in your test directory, and place your
-fixtures there. `pytest` will bring them into scope for all your tests.
+`Q3:` *I want to have my own test fixtures, and not commit them in the repo.*\
+`A3:` Add a `conftest.py` file in your test directory, and place your fixtures
+there. `pytest` will bring them into scope for all your tests.
 
 `Q4:` *I want to use more/other microvm test images, but I don't want to add
 them to the common s3 bucket.*\
-`A4:` Add your custom images to the `build/img`
-subdirectory in the Firecracker source tree. This directory is bind-mounted in
-the container and used as a local image cache.
+`A4:` Add your custom images to the `build/img` subdirectory in the Firecracker
+source tree. This directory is bind-mounted in the container and used as a local
+image cache.
 
 `Q5:` *How can I get live logger output from the tests?*\
-`A5:` Accessing
-**pytest.ini** will allow you to modify logger settings.
+`A5:` Accessing **pytest.ini** will allow you to modify logger settings.
 
 `Q6:` *Is there a way to speed up integration tests execution time?*\
-`A6:` You
-can narrow down the test selection as described in the **Running** section. For
-example:
+`A6:` You can narrow down the test selection as described in the **Running**
+section. For example:
 
 1. Pass the `-k substring` option to pytest to only run a subset of tests by
    specifying a part of their name.
@@ -643,6 +640,6 @@ sudo pip3 install pytest ipython requests psutil tenacity filelock "urllib3<2.0"
 sudo env PYTHONPATH=tests HOME=$HOME ~/.local/bin/ipython3 -i tools/sandbox.py -- --binary-dir ../repro/v1.4.1
 ```
 
-> \[!WARNING\]
+> [!WARNING]
 >
 > **Notice this runs as root!**