public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ayush Singh" <ayushdevel1325@gmail.com>
To: edk2-devel-groups-io <devel@edk2.groups.io>,
	Ayush Singh <ayushdevel1325@gmail.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>,
	michael.d.kinney@intel.com,  Jiewen Yao <jiewen.yao@intel.com>,
	jabeena.b.gaibusab@intel.com
Subject: Re: [edk2-devel] Running Rust tests for UEFI
Date: Sat, 2 Jul 2022 17:53:54 +0530	[thread overview]
Message-ID: <CA+Yfj7uCJkRcNU45-oR_kyDdScRELFiOmu3Q6ATOHMEC=G5POA@mail.gmail.com> (raw)
In-Reply-To: <16FDCB9F25F77353.5468@groups.io>

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
<ayushdevel1325=gmail.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
> 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
>
>
> 
>
>

       reply	other threads:[~2022-07-02 12:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <16FDCB9F25F77353.5468@groups.io>
2022-07-02 12:23 ` Ayush Singh [this message]
2022-07-02 19:48   ` [edk2-devel] Running Rust tests for UEFI Pedro Falcato
2022-07-03  6:25     ` Ayush Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+Yfj7uCJkRcNU45-oR_kyDdScRELFiOmu3Q6ATOHMEC=G5POA@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox