From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mx.groups.io with SMTP id smtpd.web10.49653.1656764626894358945 for ; Sat, 02 Jul 2022 05:23:47 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=bJRi3IKx; spf=pass (domain: gmail.com, ip: 209.85.167.46, mailfrom: ayushdevel1325@gmail.com) Received: by mail-lf1-f46.google.com with SMTP id e12so8018231lfr.6 for ; Sat, 02 Jul 2022 05:23:46 -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=MXFWUegfkMgy3vbmh9bYnk/t8cMqfMvaqYhvpb0ukC0=; b=bJRi3IKxrncYxbsTyuROju/5Vcro3vy1awZkLkmW116AxF9kzmL3Y5gBUVPVzz8B6d 7zlt+Rm7Uk3pujAxZx6wbW4gLevAN9Ts6+SzfF29wKJgV2BtF0PhFSDmjrR2lFeLkev6 wTZ4EZuKa3oyS22FJB4OW3yMx0RdR6JcGPdgkJ4RScJTXVZ/D2GztkxH5bj4ODXiBuK5 nh2PMAexMP0ypOGtSF+6baDBf6Wh4/wxnl+M+suOyu1KArwQPxkN7baoPJLvwxGAYfJH Kwnl4mqgq7Kxy6uoDDssC/OLRkrAUnWtbEub5TNYOP6yUcKcT6MRlSQl+lX2TgRln9vv AUSQ== 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=MXFWUegfkMgy3vbmh9bYnk/t8cMqfMvaqYhvpb0ukC0=; b=IWXB3Erc51ZWMuL3aumN+GptwJyP7fUxoDcyMrqwTcxWO03t8O9HQYANZVswKcDg6k 7M5GxiXDuOu0qabwFjBimFm0WxlJBXSnWhAOb1ltwsgnPnW81OS6MwiFAGYMlmzQzNuG v71cQMckbJpwg+gCXJBMLEtOXItcnPVGJ/mdKaAC8a85h5c+LWw4aD9xBM/APx7+aMf+ 3ju93AxQIzD1qDEuxlyFQSEHyzc6XHuCdmsYiBRjQCiZtXELbJV02/bnvtW9dFrJBxCd OUyH128AByFqT85GwnWAQYkS9OzrQ8mxpsgReHzwFvX2wp3PTp9PlGuJYBN1e1Y/4T6D Nr4g== X-Gm-Message-State: AJIora9hBW0adiXgavbZuqkgwiAyswtlKqfVjdeU40kOhyS1CS2vTCTW GBZDIyML19w1gjHzZ2uUyHFgHpjUp5RLQzsViL5Lk4J88vKo1w== X-Google-Smtp-Source: AGRyM1sRCl6m669ErkPItoC8wASz/GapGEbFKKkv0VCkcdro3MCH07B8uaet/bozM8AODDEktHJSyLs4xfB/yaW9iNo= X-Received: by 2002:a05:6512:22d0:b0:481:1bd4:5283 with SMTP id g16-20020a05651222d000b004811bd45283mr12062870lfu.581.1656764624737; Sat, 02 Jul 2022 05:23:44 -0700 (PDT) MIME-Version: 1.0 References: <16FDCB9F25F77353.5468@groups.io> In-Reply-To: <16FDCB9F25F77353.5468@groups.io> From: "Ayush Singh" Date: Sat, 2 Jul 2022 17:53:54 +0530 Message-ID: Subject: Re: [edk2-devel] Running Rust tests for UEFI To: edk2-devel-groups-io , Ayush Singh Cc: Michael Kubacki , michael.d.kinney@intel.com, Jiewen Yao , jabeena.b.gaibusab@intel.com Content-Type: text/plain; charset="UTF-8" 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. 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). 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 > > > > >