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 <ayushdevel1325@gmail.com> 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
> <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
> >
> >
> >
> >
> >
>
>
> 
>
>
>

-- 
Pedro Falcato