Some controversial-ish design decisions I've made with the fctools API. I'd like some feedback from users about whether these decisions affect their DX and how. This is to prepare for a 1.0 release where these decisions are finalized:
Dependency on nix crate. nix is not an internal dependency, it leaks out into public API with its Uid and Gid newtypes as of 0.5
Very limited (if any) support for dynamic dispatch. With #3, the vast majority of traits in the public API except for CommandModifier which is stored in a Vec<Box<dyn CommandModifier>> are now fully incompatible with dyn. For me, this is inconsequential and provides benefits by not having to run proc macros on impls of these traits, as well as reducing runtime overhead associated with future boxing, but that may not be the case for others.
Ownership limitations. Ownership is the major friction point of Firecracker SDKs, to which there are two solutions: pretend it doesn't exist (see Go SDK) or support the subset of ownership cases that makes maintainers (me) still stay sane. I've chosen the latter and 4 models are supported, which are implemented very well but do not support the "omnipresent host agent god" use-case, where 1 control process running as user A observes jailed VMs that each have a separate non-root user, i.e. B, C, D, E, F etc. Is it necessary for end-users to have this support or is the solution of 1 control process per such user attainable via fork()+setuid()?
Some controversial-ish design decisions I've made with the
fctoolsAPI. I'd like some feedback from users about whether these decisions affect their DX and how. This is to prepare for a 1.0 release where these decisions are finalized:nixcrate.nixis not an internal dependency, it leaks out into public API with itsUidandGidnewtypes as of 0.5CommandModifierwhich is stored in aVec<Box<dyn CommandModifier>>are now fully incompatible withdyn. For me, this is inconsequential and provides benefits by not having to run proc macros on impls of these traits, as well as reducing runtime overhead associated with future boxing, but that may not be the case for others.fork()+setuid()?