[Rust-VMM] interest in other Unixes?

Thu Apr 16 20:49:26 UTC 2020

Sorry about that stupid email. Not on purpose :-)

On Thu, Apr 16, 2020 at 4:48 PM Scott McCarty <smccarty at redhat.com> wrote:

> 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
>
>

-- 

-- 

[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/ff1de751/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/ff1de751/attachment-0001.png>