[Rust-VMM] interest in other Unixes?

Andreea Florescu andreea.florescu15 at gmail.com
Thu Apr 16 08:46:16 UTC 2020


Oh, I like spamming.

I meant delete the Display test, not the implementation.


On Thu, Apr 16, 2020 at 11:44 AM Andreea Florescu <
andreea.florescu15 at gmail.com> wrote:

> Hey Allison,
>
> > How interested would you be in patches for Unix family operating systems
> > other than Linux?
>
> I think it makes sense to support other Unix families. We just have to
> make sure we keep a clean separation and general tidiness in the
> code while adding support for other platforms/OSes/stuff. This can
> be discussed during code review.
>
> > 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.
>
> This sounds like a bug in vmm-sys-util to me. If the code only works on
> Linux, it should be labeled as such. I don't see any problem in changing
> it from Unix to Linux.
>
> > 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.
>
> I don't think Display should be tested at all because this particular
> implementation of Display relies on `io::Error` implementation of
> Display. We're just basically forwarding the implementation. We can
> either delete the Display implementation (which would make me very
> happy :)) ) or use some other errors where the wording is the same
> (are there any errors like that?).
>
> I look forward to your PRs.
>
> Andreea
>
>
> On Thu, Apr 16, 2020 at 5:58 AM Iggy Jackson (Brian) <notiggy at gmail.com>
> wrote:
>
>>
>>
>> > 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
>>
>>
>> _______________________________________________
>> Rust-vmm mailing list
>> Rust-vmm at lists.opendev.org
>> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20200416/146b4686/attachment-0001.html>


More information about the Rust-vmm mailing list