[Rust-VMM] interest in other Unixes?

Thu Apr 16 20:48:43 UTC 2020

UNSUBSCRIBE

On Thu, Apr 16, 2020 at 4:46 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
>>
> _______________________________________________
> Rust-vmm mailing list
> Rust-vmm at lists.opendev.org
> http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm
>

-- 

-- 

[image: Summit Virtual Experience]
<https://www.redhat.com/en/summit?sc_cid=7013a000002D2QxAAK>

Scott McCarty
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: smccarty at redhat.com
Phone: 312-660-3535
Cell: 330-807-1043
Web: http://crunchtools.com

Using Azure Pipelines with Red Hat Universal Base Image and Quay.io:
https://red.ht/2TvYo3Y
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20200416/f30595f5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rh-summit-email-assets-us226039-201909sw-virtualevent-v2_sig-340x150-left-b.png
Type: image/png
Size: 13402 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20200416/f30595f5/attachment-0001.png>