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....@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 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#91010): https://edk2.groups.io/g/devel/message/91010 Mute This Topic: https://groups.io/mt/92117896/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
