From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by mx.groups.io with SMTP id smtpd.web12.58185.1656829548285881132 for ; Sat, 02 Jul 2022 23:25:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=XxEbHUmZ; spf=pass (domain: gmail.com, ip: 209.85.208.170, mailfrom: ayushdevel1325@gmail.com) Received: by mail-lj1-f170.google.com with SMTP id a11so7320320ljb.5 for ; Sat, 02 Jul 2022 23:25:48 -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:content-transfer-encoding; bh=HS2Mj6be1pc1TF+UEXKMV9Mj6gLxEptdizmsmN2zqdc=; b=XxEbHUmZx8Vhr3ar1z2F98WsIma4zHl6w5L3X1HG/z29tfEOQ6VusLORLEaJ13Z0Mu Jaw9tgzH6+U49DeGZLd+KlHkXCIOP+hqGQLf8PN1/scZ46v9SSuSRjHLRZx6gDLeLYWk AaO0i3TUoc/cfrBQz3FfWWROe9cZ/bTJqp/L02xjuSJDNzflgcz6z1DMSABIv/hprMm7 uFVcuyVFqoUACRZMVOO/wCba+LhDCYeJXL7OCSIx5LREnK+wHMNV3etL2d8etewEZmWL SxQNzkry57loEVNmJZWwcJTgxwkiAL9bDwkfKdWFDwV3DhtzEoT7fdOIo96xmizSrIdh E+4w== 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:content-transfer-encoding; bh=HS2Mj6be1pc1TF+UEXKMV9Mj6gLxEptdizmsmN2zqdc=; b=7FDfbd9Ugxjt7d95WsVBZUAYZ05PMoCFae58hrVtUTs1YSKNFRwmkuQqemdxRBzxl4 eRm1dMjInrxMA5H4D1bQ6oD0arbpWv0z7OjlDOgCIMn2ot81maqzNiN1esx+TPE0BOVW GW+9Fo5Y5sXWiJrK45FzKh8G4DZsYk6ZRVRwNxzSwe9qGUNYr/nTxhLcoy6ZmzH0gb+u 5S0DOu5p0N5cM2LZpbN7cenGm+s0zX3Tu0khRAgJZhpVfsuBQlMA6OuVfpjyaz2MeILF f0lmodROeKd5OkvJ5JK7y6+bvQSHVTjiro7oi7BBXBH4DNl00cHhwUjyFzI5+yyPc0Wd ERCQ== X-Gm-Message-State: AJIora8l/H8V8KqXcrNESmwo9UPS3nAq/MvhXlknaOrNYkIjf0s/L7oG AxaGEcwcgodypWSE9YcRpIp8vxw7eDy1DLPxmqM= X-Google-Smtp-Source: AGRyM1vI6GczO7NXY/C8bjOgmiUz0cnaOt8NPrWKI9rBOI6FYaPMUsGyw6cMMg/GI0pGGdO6ixHnNMGU9qzcp6dK0Sc= X-Received: by 2002:a2e:b8c2:0:b0:25b:6b0c:34e with SMTP id s2-20020a2eb8c2000000b0025b6b0c034emr3629516ljp.397.1656829546077; Sat, 02 Jul 2022 23:25:46 -0700 (PDT) MIME-Version: 1.0 References: <16FDCB9F25F77353.5468@groups.io> In-Reply-To: From: "Ayush Singh" Date: Sun, 3 Jul 2022 11:55:34 +0530 Message-ID: Subject: Re: [edk2-devel] Running Rust tests for UEFI To: Pedro Falcato Cc: edk2-devel-groups-io , Michael Kubacki , "Kinney, Michael D" , Jiewen Yao , jabeena.b.gaibusab@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Here's my 2 cents: don't worry too much about tests, if that will slow yo= u down considerably. You should focus on getting a usable runtime environme= nt first, tests should be a secondary thing on your mind (we don't have man= y tests in EDK2 anyway, despite some ongoing efforts). Well, I have implemented enough std to make it possible to build for UEFI like the official Rust targets. There are around 13,000 tests in the Rust CI that are platform agnostic and are run for all Tier 1 and Tier 2 targets with std support. Since the final goal is to get the UEFI std upstreamed, it kinda needs to be able to run these tests. > I don't know about their availability, but I would consider only supporti= ng tests on firmware which has the TCP and UDP protocols; re-implementing T= CP is totally non-trivial. Ok, that sounds good to me. > 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. I think you might have misunderstood a bit. In the current implementation of net stuff in Rust, basically, the platform seems to handle selecting the device and all. However, in UEFI, the `LocateHanldle` returns an array of all the devices that implement the protocol. So well, the internal implementation will need to select which device to connect to. Basically, it is not possible to change the signatures of any of the net stuff (to take the handle as input) just for UEFI. Ayush Singh On Sun, Jul 3, 2022 at 1:18 AM Pedro Falcato wrot= e: > > Hi, > > Here's my 2 cents: don't worry too much about tests, if that will slow yo= u down considerably. You should focus on getting a usable runtime environme= nt first, tests should be a secondary thing on your mind (we don't have man= y tests in EDK2 anyway, despite some ongoing efforts). > > On Sat, Jul 2, 2022 at 1:23 PM Ayush Singh wro= te: >> >> 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 supporti= ng tests on firmware which has the TCP and UDP protocols; re-implementing T= CP 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-te= st-client >> > [3]: https://github.com/rust-lang/rust/tree/master/src/tools/remote-te= st-server >> > [4]: https://github.com/rust-lang/rust/blob/5b9775fe17893cba641a071de7= e0a7c8f478c41b/library/std/src/sys/unsupported/net.rs >> > >> > >> > >> > >> > >> >> >>=20 >> >> > > > -- > Pedro Falcato