<div dir="ltr"><div class="gmail_default" style="font-size:small">UNSUBSCRIBE</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 4:46 AM Andreea Florescu <<a href="mailto:andreea.florescu15@gmail.com">andreea.florescu15@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey Allison,</div><div><br></div><div><span>> How interested would you be in patches for Unix family operating systems<br>
> other than Linux?</span></div><div><span><br></span></div><div><span>I think it makes sense to support other Unix families. We just have to</span></div><div><span>make sure we keep a clean separation and general tidiness in the</span></div><div><span>code while adding support for other platforms/OSes/stuff. This can</span></div><div><span>be discussed during code review.<br></span></div><div><span><br></span></div><div><span>> As a concrete example of how non-disruptive this can be, the patch I'm<br>
> debating whether to submit is a 4 line substitution in vmm-sys-util,<br>
> which changes [#cfg(unix)] to [#cfg(linux)]. Right now, those lines are<br>
> checking for target_family = "unix", but the code in question is<br>
> actually unique to Linux, and fails to compile on other Unix family<br>
> operating systems (mostly due to type errors, and using features that<br>
> only exist on Linux), so it really should be checking target_os =<br>
> "linux" instead.</span></div><div><span><br></span></div><div><span>This sounds like a bug in vmm-sys-util to me. If the code only works on</span></div><div><span>Linux, it should be labeled as such. I don't see any problem in changing</span></div><div><span>it from Unix to Linux.</span></div><div><span><br></span></div><div><span><span>> src/<a href="http://errno.rs" rel="noreferrer" target="_blank">errno.rs</a> testing a very specific string message as the text for<br>
> libc::EBADF, which has slightly different wording on other Unix family<br>
> operating systems.</span></span></div><div><span><span><br></span></span></div><div><span><span>I don't think Display should be tested at all because this particular</span></span></div><div><span><span>implementation of Display relies on `io::Error` implementation of</span></span></div><div><span><span>Display. We're just basically forwarding the implementation. We can</span></span></div><div><span><span>either delete the Display implementation (which would make me very</span></span></div><div><span><span>happy :)) ) or use some other errors where the wording is the same</span></span></div><div><span><span>(are there any errors like that?).</span></span></div><div><span><span><br></span></span></div><div><span><span>I look forward to your PRs.</span></span></div><div><span><span><br></span></span></div><div><span><span>Andreea<br></span></span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 5:58 AM Iggy Jackson (Brian) <<a href="mailto:notiggy@gmail.com" target="_blank">notiggy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Apr 15, 2020, at 1:39 PM, Allison Randal <<a href="mailto:allison@lohutok.net" target="_blank">allison@lohutok.net</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> How interested would you be in patches for Unix family operating systems<br>
> other than Linux? I'm working on a prototype lightweight VMM on the<br>
> Illumos Kernel and Bhyve ioctl interface, and I'm planning to reuse<br>
> rust-vmm libraries where I can. I prefer to work upstream on shared<br>
> libraries, but I totally understand if the focus here is Linux, and<br>
> patches for other Unix family operating systems are undesirable.<br>
<br>
Rust-VMM is such a moving target at the moment, you basically _have_ <br>
to work on upstream. <br>
<br>
> <br>
> As a concrete example of how non-disruptive this can be, the patch I'm<br>
> debating whether to submit is a 4 line substitution in vmm-sys-util,<br>
> which changes [#cfg(unix)] to [#cfg(linux)]. Right now, those lines are<br>
> checking for target_family = "unix", but the code in question is<br>
> actually unique to Linux, and fails to compile on other Unix family<br>
> operating systems (mostly due to type errors, and using features that<br>
> only exist on Linux), so it really should be checking target_os =<br>
> "linux" instead. The specific changes are lines 8, 17, and 19, in<br>
> src/<a href="http://lib.rs" rel="noreferrer" target="_blank">lib.rs</a>, which determine whether to use the code in the<br>
> architecture-specific 'unix' directory, and whether to use the bitflags<br>
> library (which is only used by the 'unix' directory). And, line 183 in<br>
> src/<a href="http://errno.rs" rel="noreferrer" target="_blank">errno.rs</a> testing a very specific string message as the text for<br>
> libc::EBADF, which has slightly different wording on other Unix family<br>
> operating systems.<br>
> <br>
> That simple substitution makes it possible to use both vmm-sys-util and<br>
> vm-memory on Illumos (since vm-memory was only using<br>
> architecture-independent parts of vmm-sys-util for temp files in tests,<br>
> and nothing in the 'unix' directory). I haven't started systematically<br>
> testing other rust-vmm libraries for non-Linux compatibility yet, but I<br>
> expect I'll find similar patterns.<br>
<br>
I can't speak for everyone (or anyone for that matter, I'm just a<br>
bystander here), but I think as long as things don't turn into a<br>
spaghetti ball of conditionals, targeting other unixes is a good thing.<br>
<br>
I think your best bet is to send a couple of small PRs and see what the<br>
response is. I suspect the devs will be open to most of it. Anything<br>
that is untenable can either live outside in a separate library or just<br>
a straight fork of certain crates. That already kind of exists currently<br>
between firecracker, cloud-hypervisor, and rust-vmm (although they are<br>
working to merge some of that where it makes sense).<br>
<br>
> <br>
> (Full disclosure: I personally prefer Linux Kernel and KVM, but this is<br>
> paid work, and sparks enough intellectual curiosity for me to be willing<br>
> to do it.)<br>
<br>
Good to hear. The more companies that start building around rust-vmm the<br>
better.<br>
<br>
> <br>
> Thanks for any thoughts,<br>
> Allison<br>
> <br>
> _______________________________________________<br>
> Rust-vmm mailing list<br>
> <a href="mailto:Rust-vmm@lists.opendev.org" target="_blank">Rust-vmm@lists.opendev.org</a><br>
> <a href="http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm" rel="noreferrer" target="_blank">http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm</a><br>
<br>
<br>
_______________________________________________<br>
Rust-vmm mailing list<br>
<a href="mailto:Rust-vmm@lists.opendev.org" target="_blank">Rust-vmm@lists.opendev.org</a><br>
<a href="http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm" rel="noreferrer" target="_blank">http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm</a><br>
</blockquote></div>
_______________________________________________<br>
Rust-vmm mailing list<br>
<a href="mailto:Rust-vmm@lists.opendev.org" target="_blank">Rust-vmm@lists.opendev.org</a><br>
<a href="http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm" rel="noreferrer" target="_blank">http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><pre>-- <br></pre><pre><a href="https://www.redhat.com/en/summit?sc_cid=7013a000002D2QxAAK" target="_blank"><img src="cid:ii_k85znh9l1" alt="Summit Virtual Experience"></a></pre><pre><font size="2">Scott McCarty
Product Management - Containers, Red Hat Enterprise Linux & OpenShift
Email: <a href="mailto:smccarty@redhat.com" target="_blank">smccarty@redhat.com</a>
Phone: 312-660-3535
Cell: 330-807-1043
Web: <a href="http://crunchtools.com" target="_blank">http://crunchtools.com</a></font><pre>Using Azure Pipelines with Red Hat Universal Base Image and Quay.io: <a href="https://red.ht/2TvYo3Y" target="_blank">https://red.ht/2TvYo3Y</a></pre></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>