On Sat, Mar 4, 2023 at 12:41 PM David Michael <fedora.dm0@xxxxxxxxx> wrote: > > Hi, > > Firecracker[0] is a minimal virtual machine manager (a la QEMU) > written in Rust that uses KVM to start Linux VMs extremely quickly and > securely. It is used by AWS Lambda and Fargate among other things to > make VM startup time comparable to containers. I've built it for > Fedora x86_64 and shared it in a Copr repository[1] which includes > some example commands for starting VMs. > > Making it build for Fedora required changes across a few components, > so I'm writing to ask if this is acceptable for inclusion in Fedora. > The Copr specs are all dumped in a Git repository[2] for readability. > Changes include: > > - The musl package adds /usr paths for compatibility with the > compiler --sysroot option. As the musl package maintainer, I don't particularly want Fedora packages depending on it unless they absolutely have to. I originally maintained it in Copr, but brought it into Fedora for the Enarx folks. I still maintain that generally you don't want to use this unless you *really* know what you're doing and can deal with the consequences of using an alternative libc. That said, the changes you make are not currently compatible with the packaging guidelines. Can't you just use --prefix /usr/<target> instead? > - The rust compiler adds musl target subpackages. This will require discussion with the Fedora Rust SIG. > - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be > usable as a guest. This will require talking to the kernel maintainers to add the flag. > - About two dozen Rust crates must be added to Fedora (but a handful > are just new versions of existing packages). > - Unrelated, but in the Copr repo anyway: The musl package is fixed > to allow multilib installs, and Rust includes both 32- and 64-bit > targets. > > I used upstream-preferred settings when adding things, but they may be > in conflict with Fedora guidelines. Here are some concerns: > > - Firecracker can be built with Fedora's libc (glibc), but it is > officially unsupported upstream[3]. Functionality would be harmed by > not using musl, e.g. seccomp filters are not used. Why not drive this to be fixed upstream? Also, openSUSE builds Firecracker against glibc and I see the seccomp stuff is also produced and shipped[1]. I am not sure whether this means openSUSE's package is broken or something else. [1]: https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec > - Upstream Rust wants musl targets to be statically linked by > default[4]. It can be changed by patching (Gentoo does this) if > dynamic linking is still a priority with Rust binaries, but I haven't > tested that. As in musl is statically linked into the binaries? Or the Rust code is statically linked. The former is not okay, the latter is what we do already. > - Firecracker uses two crates forked from crates.io, but they are > not vendored/bundled nor published to a registry. I'm currently > manually bundling them as if they were vendored to avoid package name > conflicts since nothing else uses them, but I don't know the preferred > way to deal with those. > That's probably the right way to deal with it. > So does any of that sound like a showstopper for being included in > Fedora? Is there any other interest in the project from the > community? > It'd be interesting to have in Fedora, for sure, but this should be done as an opportunity to bring our integration concerns upstream. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
