I think for 1.0 we want it so that cfsctl can be used via a subprocess from non-Rust languages. I think it'd even be mainly viable to have bootc mostly fork cfsctl as a subprocess (e.g. for the meaty stuff like listing/pulling/removing images, fsck). We'd probably still want to link the crate just for various convenience functions (e.g. uki/karg parsing) but it would probably avoid a lot of code being duplicated between bootc and cfsctl.
We could talk a lot about possible choices here, but I think varlink is OK. I have gone back and forth on this myself a ton (see e.g. podman-container-tools/buildah#6675 ).
FD passing
The biggest thing I had issues with. The status quo right now is systemd does this, but it's not part of the varlink standard, and when I looked their implementation has some issues. One thing at least that is nice about varlink is it does support upgrade to cut over to other protocols - it's probably not fatal to have anything we do that needs fd passing cut over to jsonrpc-fdpass.
I think for 1.0 we want it so that
cfsctlcan be used via a subprocess from non-Rust languages. I think it'd even be mainly viable to have bootc mostly fork cfsctl as a subprocess (e.g. for the meaty stuff like listing/pulling/removing images, fsck). We'd probably still want to link the crate just for various convenience functions (e.g. uki/karg parsing) but it would probably avoid a lot of code being duplicated between bootc and cfsctl.We could talk a lot about possible choices here, but I think varlink is OK. I have gone back and forth on this myself a ton (see e.g. podman-container-tools/buildah#6675 ).
FD passing
The biggest thing I had issues with. The status quo right now is systemd does this, but it's not part of the varlink standard, and when I looked their implementation has some issues. One thing at least that is nice about varlink is it does support
upgradeto cut over to other protocols - it's probably not fatal to have anything we do that needs fd passing cut over to jsonrpc-fdpass.