[Rust-VMM] interest in other Unixes?

[Iggy Jackson (Brian)]

> On Apr 15, 2020, at 1:39 PM, Allison Randal <allison at lohutok.net> wrote:
> 
> Hi all,
> 
> How interested would you be in patches for Unix family operating systems
> other than Linux? I'm working on a prototype lightweight VMM on the
> Illumos Kernel and Bhyve ioctl interface, and I'm planning to reuse
> rust-vmm libraries where I can. I prefer to work upstream on shared
> libraries, but I totally understand if the focus here is Linux, and
> patches for other Unix family operating systems are undesirable.

Rust-VMM is such a moving target at the moment, you basically _have_ 
to work on upstream. 

> 
> As a concrete example of how non-disruptive this can be, the patch I'm
> debating whether to submit is a 4 line substitution in vmm-sys-util,
> which changes [#cfg(unix)] to [#cfg(linux)]. Right now, those lines are
> checking for target_family = "unix", but the code in question is
> actually unique to Linux, and fails to compile on other Unix family
> operating systems (mostly due to type errors, and using features that
> only exist on Linux), so it really should be checking target_os =
> "linux" instead. The specific changes are lines 8, 17, and 19, in
> src/lib.rs, which determine whether to use the code in the
> architecture-specific 'unix' directory, and whether to use the bitflags
> library (which is only used by the 'unix' directory). And, line 183 in
> src/errno.rs testing a very specific string message as the text for
> libc::EBADF, which has slightly different wording on other Unix family
> operating systems.
> 
> That simple substitution makes it possible to use both vmm-sys-util and
> vm-memory on Illumos (since vm-memory was only using
> architecture-independent parts of vmm-sys-util for temp files in tests,
> and nothing in the 'unix' directory). I haven't started systematically
> testing other rust-vmm libraries for non-Linux compatibility yet, but I
> expect I'll find similar patterns.

I can't speak for everyone (or anyone for that matter, I'm just a
bystander here), but I think as long as things don't turn into a
spaghetti ball of conditionals, targeting other unixes is a good thing.

I think your best bet is to send a couple of small PRs and see what the
response is. I suspect the devs will be open to most of it. Anything
that is untenable can either live outside in a separate library or just
a straight fork of certain crates. That already kind of exists currently
between firecracker, cloud-hypervisor, and rust-vmm (although they are
working to merge some of that where it makes sense).

> 
> (Full disclosure: I personally prefer Linux Kernel and KVM, but this is
> paid work, and sparks enough intellectual curiosity for me to be willing
> to do it.)

Good to hear. The more companies that start building around rust-vmm the
better.

> 
> Thanks for any thoughts,
> Allison
> 
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm