Merge pull request #3 from firecracker-microvm/main

Merge upstream firecracker repo changes

Author: CompuIves

.dockerignore

@@ -0,0 +1,5 @@
+.git/
+build/
+src/
+tests/
+docs/

.git-blame-ignore-revs

@@ -0,0 +1,2 @@
+8d2463fa21386d6c0c90b2010aaee5550b505c87
+ae93e49470433648b144a64514eef708cce15143

CONTRIBUTING.md

@@ -57,7 +57,15 @@ If you just want to receive feedback for a contribution proposal, open an “RFC
 ## Contribution Quality Standards
 
 Most quality and style standards are enforced automatically during integration
-testing. Your contribution needs to meet the following standards:
+testing. For ease of use you can setup a git pre-commit hook by running the
+following in the Firecracker root directory:
+
+```
+cargo install rusty-hook
+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
@@ -68,6 +76,17 @@ testing. Your contribution needs to meet the following standards:
 - 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
+
+  ```
+  A descriptive title of 50 characters or fewer
+
+  A concise description where each line is 72 characters or fewer.
+
+  Signed-off-by: <A full name> <A email>
+  Co-authored-by: <B full name> <B email>
+  ```
+
 - 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

Cargo.lock

@@ -9,14 +9,8 @@ definition, a call to one of the [API Endpoints](#api-endpoints) will succeed.
 
 **R** - Required: The device (column) **is required** for a Firecracker microVM
 API call to succeed. If the device (column) is omitted from a uVM definition,
-a call to one of the [API Endpoints](#api-endpoints) will return a result that
-depends on the device (see [issue #2173](https://github.com/firecracker-microvm/firecracker/issues/2173)).
-
-- API calls related to `drives/{id}` result in 400 - BadRequest - HTTP response
-  if the block device identified by `id` was not previously configured.
-- API calls related to `network-interfaces/{id}` result in 400 - BadRequest -
-  HTTP response if the network device identified by `id` was not previously
-  configured.
+a call to one of the [API Endpoints](#api-endpoints) will fail with a
+400 - BadRequest - HTTP response.
 
 ## API Endpoints
 

docs/device-api.md

@@ -60,7 +60,7 @@ curl -L ${release_url}/download/${latest}/firecracker-${latest}-${arch}.tgz \
 Rename the binary to "firecracker":
 
 ```console
-mv firecracker-${latest}-$(uname -m) firecracker
+mv release-${latest}-$(uname -m)/firecracker-${latest}-$(uname -m) firecracker
 ```
 
 If, instead, you'd like to build Firecracker yourself, you should check out

docs/getting-started.md

@@ -61,6 +61,7 @@ on which Firecracker is run:
 ### ARM
 
 * timekeeping - `CONFIG_ARM_AMBA`, `CONFIG_RTC_DRV_PL031`
+* serial console - `CONFIG_SERIAL_OF_PLATFORM`
 
 ### x86_64
 

docs/kernel-policy.md

@@ -290,7 +290,7 @@ for restoring does not support persisting the version, the default will be used.
 
 ### MMDS formats
 
-The response format can be JSON (experimental) or IMDS. The IMDS documentation
+The response format can be JSON or IMDS. The IMDS documentation
 can be found [here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).
 The output format can be selected by specifying the optional `Accept` header.
 Using `Accept: application/json` will format the output to JSON, while using