From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by mx.groups.io with SMTP id smtpd.web11.53436.1656791319918300982 for ; Sat, 02 Jul 2022 12:48:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Y7pdUi91; spf=pass (domain: gmail.com, ip: 209.85.221.176, mailfrom: pedro.falcato@gmail.com) Received: by mail-vk1-f176.google.com with SMTP id 37so2703484vkl.7 for ; Sat, 02 Jul 2022 12:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8GkxuY4+nyXGCEE1yo67LmZ3GS6kR8Z6oR0QChErWGQ=; b=Y7pdUi916tKJrng85PTCQtC4YnGFP65CkRBgzNd0G4sb1aseX1MjIODfAiyLa5TbeJ I994+BBXXYysCOeeU3KLi2UCjSFqqIZl6nvPEaJUrZl6zHIL7OX89dV3ZcwXaSlFRNk/ pf6eRrgdKZaOF+vt3Hx0dx1N1AcI+WQQ5hYaneUScKpLnI3GV+fqn++KKfSTHUHfMGJy p6+VTdHqXjoc9Ix/X6Bf2vipCX2IPS57sx6n2Vlz73699qxs65zEMPodUnDQhOQUf5mr jnSzfo4Lx+E7pl5R39fwwv3qz00W+MNOaI2BsIY11p8EPILeeDU8TNsY+7i0YtlRykb1 eHwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8GkxuY4+nyXGCEE1yo67LmZ3GS6kR8Z6oR0QChErWGQ=; b=FMNdlAM/bDzPxFAaYJOluEv7U8a/ul54/gUyn3bxO2MebfR73BMuSWqHgRO22iFtbj +HXNSeG9bkxoO2hwCt2hao+OP+2WIW+xIGSoa4Oq5/oa7mcHX4ufyFEBHppQhq9UMu7V uNNJHRO5sjP04ZSWApkSS+TY+7t8hz4ELjUKyuBGpu2FNT8tLFtAIj0avsbzz1VOR6zc qKLkxS9J87dNLWC5y88ggYf2zpqZJf9sZzcAc3KWyaoULOxRxXIktXNLWUH8det2/QqW GrJUGHpO61OKa/2ABWR+IKNaDpdPISscV+V25iGwYPo/bf5Eq4ARPdtHDTEPS6xA8vAE n0bw== X-Gm-Message-State: AJIora+1OhEhahlYBZ8q8Qaj7sL1UShlAvwonuJhhWi5YZURQetYqrTG c5VEH1nQ/GxF8fr+vh/oyj4IQIpbHdH42uTrT4ZQ6ivAzGTkNQ== X-Google-Smtp-Source: AGRyM1tz6EpNcEEdaPNwdVzzMHLVwlAL47Blqt8WFzqfKa+BPnBE5Q80qLqOoIiWSArYKFq+bamS9UwxBcWPxeM0bd0= X-Received: by 2002:a1f:a612:0:b0:36c:67c1:e3b0 with SMTP id p18-20020a1fa612000000b0036c67c1e3b0mr14668443vke.20.1656791318724; Sat, 02 Jul 2022 12:48:38 -0700 (PDT) MIME-Version: 1.0 References: <16FDCB9F25F77353.5468@groups.io> In-Reply-To: From: "Pedro Falcato" Date: Sat, 2 Jul 2022 20:48:27 +0100 Message-ID: Subject: Re: [edk2-devel] Running Rust tests for UEFI To: edk2-devel-groups-io , Ayush Singh Cc: Michael Kubacki , "Kinney, Michael D" , Jiewen Yao , jabeena.b.gaibusab@intel.com Content-Type: multipart/alternative; boundary="0000000000000504da05e2d7caf4" --0000000000000504da05e2d7caf4 Content-Type: text/plain; charset="UTF-8" Hi, Here's my 2 cents: don't worry too much about tests, if that will slow you down considerably. You should focus on getting a usable runtime environment first, tests should be a secondary thing on your mind (we don't have many tests in EDK2 anyway, despite some ongoing efforts). On Sat, Jul 2, 2022 at 1:23 PM Ayush Singh wrote: > After some more research, I have found 2 main ways of implementing net: > > 1. Use the TCP and UDP protocols defined in UEFI spec. They seem > pretty easy to use. But while they are an official protocol, the > availability is shoddy (r-efi does not define either of them). Still > should work well enough if testing is the main reason for implementing > them. > > 2. Use Simple Network Protocol (SNP). This is a very basic protocol > that basically allows transmitting and receiving packets. Availability > is pretty good, but implementing TCP and UDP using it will require a > lot of work. > > So I wanted to ask about the availability of TCP and UDP protocols vs > SNP? If the TCP and UDP protocols are likely to be available in > presence of SNP, then well, I will directly use those. > I don't know about their availability, but I would consider only supporting tests on firmware which has the TCP and UDP protocols; re-implementing TCP is totally non-trivial. > > Also, how should I handle when multiple Handles are returned by > `LocateHandle`? One option can be to use the 1st handle by default but > provide functions under `std::os` to allow users to use a particular > handle if they want (although this will mean caching the Handle). > > I'm not big into Rust but isn't there a way to just pass a reference into an array into a function? You'd essentially just do that. > Since all the functions in net return `Result` we can just return an > error if the device does not have networking support. > > Ayush Singh > > On Sat, Jul 2, 2022 at 1:05 AM Ayush Singh via groups.io > wrote: > > > > Hello everyone, the project has now reached the stage where it is > > possible to build for UEFI just like an std supporting Rust target. > > However, running tests is where it gets a bit tricky: > > > > While there are some rust targets that run on QEMU emulation for > > testing [1] (as opposed to just docker), this is currently achieved by > > 2 tools: remote-test-client [2] and remote-test-server [3] which are > > programs for sending test programs and libraries to the emulator, and > > running the tests within the emulator, and reading the results. > > > > This means that the rust-test-server [3] needs to run in the UEFI > > environment. This means it needs the `sys::net` module implemented. As > > suggested in the last meeting, I was using a dummy implementation of > > net. However, for using the current Rust testing environment, we > > simply need to implement net. > > > > There is also the alternative of using stdio in qemu for testing, but > > that will mean significant reworking of the Rust testing framework > > (which seems to be more difficult than implementing `net`) > > > > So I think that it would be better to implement the `net` module > > first. The primitives that need to be implemented in this module are > > TcpSocket, TcpListener, and UdpSocket (unsupported version link [4]). > > > > So should I go ahead with implementing `net`? Is there anything > > special that I should consider? > > > > Yours Sincerely, > > Ayush Singh > > > > [1]: > https://rustc-dev-guide.rust-lang.org/tests/running.html#testing-on-emulators > > [2]: > https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-client > > [3]: > https://github.com/rust-lang/rust/tree/master/src/tools/remote-test-server > > [4]: > https://github.com/rust-lang/rust/blob/5b9775fe17893cba641a071de7e0a7c8f478c41b/library/std/src/sys/unsupported/net.rs > > > > > > > > > > > > > > > > -- Pedro Falcato --0000000000000504da05e2d7caf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here= 9;s my 2 cents: don't worry too much about tests, if that will slow you= down considerably. You should focus on getting a usable runtime environmen= t first, tests should be a secondary thing on your mind (we don't have = many tests in EDK2 anyway, despite some ongoing efforts).

On Sat, Jul = 2, 2022 at 1:23 PM Ayush Singh <ayushdevel1325@gmail.com> wrote:
After some more research, I have found 2 main w= ays of implementing net:

1. Use the TCP and UDP protocols defined in UEFI spec. They seem
pretty easy to use. But while they are an official protocol, the
availability is shoddy (r-efi does not define either of them). Still
should work well enough if testing is the main reason for implementing
them.

2. Use Simple Network Protocol (SNP). This is a very basic protocol
that basically allows transmitting and receiving packets. Availability
is pretty good, but implementing TCP and UDP using it will require a
lot of work.

So I wanted to ask about the availability of TCP and UDP protocols vs
SNP? If the TCP and UDP protocols are likely to be available in
presence of SNP, then well, I will directly use those.
I don't know about their availability, but I would consider only suppo= rting tests on firmware which has the TCP and UDP protocols; re-implementing TCP is totally non-trivial.

Also, how should I handle when multiple Handles are returned by
`LocateHandle`? One option can be to use the 1st handle by default but
provide functions under `std::os` to allow users to use a particular
handle if they want (although this will mean caching the Handle).

I'm not big into Rust but isn't there a way t= o just pass a reference into an array into a function? You'd essentiall= y just do that.
Since all the functions in net return `Result` we can just return an
error if the device does not have networking support.

Ayush Singh

On Sat, Jul 2, 2022 at 1:05 AM Ayush Singh via groups.io
<ayushdevel1325=3Dgmail.com@groups.io> wrote:
>
> Hello everyone, the project has now reached the stage where it is
> possible to build for UEFI just like an std supporting Rust target. > However, running tests is where it gets a bit tricky:
>
> While there are some rust targets that run on QEMU emulation for
> testing [1] (as opposed to just docker), this is currently achieved by=
> 2 tools: remote-test-client [2] and remote-test-server [3] which are > programs for sending test programs and libraries to the emulator, and<= br> > running the tests within the emulator, and reading the results.
>
> This means that the rust-test-server [3] needs to run in the UEFI
> environment. This means it needs the `sys::net` module implemented. As=
> suggested in the last meeting, I was using a dummy implementation of > net. However, for using the current Rust testing environment, we
> simply need to implement net.
>
> There is also the alternative of using stdio in qemu for testing, but<= br> > that will mean significant reworking of the Rust testing framework
> (which seems to be more difficult than implementing `net`)
>
> So I think that it would be better to implement the `net` module
> first. The primitives that need to be implemented in this module are > TcpSocket, TcpListener, and UdpSocket (unsupported version link [4]).<= br> >
> So should I go ahead with implementing `net`? Is there anything
> special that I should consider?
>
> Yours Sincerely,
> Ayush Singh
>
> [1]: https://rustc= -dev-guide.rust-lang.org/tests/running.html#testing-on-emulators
> [2]: https://github.c= om/rust-lang/rust/tree/master/src/tools/remote-test-client
> [3]: https://github.c= om/rust-lang/rust/tree/master/src/tools/remote-test-server
> [4]: https://github.com/rust-lang/rust/blob/5b9775fe= 17893cba641a071de7e0a7c8f478c41b/library/std/src/sys/unsupported/net.rs=
>
>
>
>
>







--
Pedro Falcato
--0000000000000504da05e2d7caf4--