Alyssa Ross 4ca18c082e vmm: use trait objects for API actions ... Uses of the old ApiRequest enum conflated two different concerns: identifying an API request endpoint, and storing data for an API request. This led to ApiRequest values being passed around with junk data just to communicate a request type, which forced all API request body types to implement Default, which in some cases doesn't make any sense — what's the "default" path for a vhost-user socket? The nonsensical Default values have led to tests relying on being able to use nonsensical data, which is an impediment to adding better validation for these types. Rather than having API request types be represented by an enum, which has to carry associated body data everywhere it's used, it makes more sense to represent API request types as trait objects. These can have an associated type for the type of the request body, and this makes it possible to pass API request types and data around as siblings in a type-safe way without forcing them into a single value even where it doesn't make sense. Trait objects also give us dynamic dispatch, which lets us get rid of several large match blocks. To keep it possible to fuzz the HTTP API, all the Vmm methods called by the HTTP API are pulled out into a trait, so the fuzzer can provide its own stub implementation of the VMM. Signed-off-by: Alyssa Ross <hi@alyssa.is>		2024-01-17 10:20:02 +00:00
..
src	vmm: use trait objects for API actions	2024-01-17 10:20:02 +00:00
Cargo.toml	vmm: use RateLimiterGroup for virtio-blk devices	2024-01-03 10:21:06 -08:00