Date
1 - 3 of 3
Clarification about UEFI networking stack
|
Michael D Kinney
Yes. MNP is the lowest network stack layer that is guaranteed to be present for every Network Device.
This link to one section earlier describes the options for Network Device vendors. They can choose to implement UNDI, or SNP, or MNP. If they choose UNDI, then that platform can produce SNP and MNP for the network device. If they choose SNP, then the platform can produce MNP for the network device. https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines Best regards, Mike From: Ayush Singh <ayushdevel1325@...> Sent: Friday, December 9, 2022 10:04 AM To: discuss@edk2.groups.io Cc: Kinney, Michael D <michael.d.kinney@...>; Michael Kubacki <mikuback@...> Subject: Clarification about UEFI networking stack Hello everyone, I am thinking about writing better networking for UEFI Rust development. As such, I was trying to understand the relation and availability of UNDI/NII, SNP, MNP, TCP protocols, etc. What would be the best protocol to base the networking stack on? From this [1] documentation I found, it seems that as long as SNP is implemented, MNP will be layered on top of SNP by firmware. So can I assume that at least MNP will almost always be available if networking is present in any form? Yours Sincerely Ayush Singh [1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines/252_nii_protocol_and_undi_implementations |
|
|
|
A rust-based stack for edkII would be interesting. https://github.com/smoltcp-rs/smoltcp might have some code to leverage?
toggle quoted message
Show quoted text
A model of importing an alternate network stack into edkII, in this case Lwip https://savannah.nongnu.org/projects/lwip/, is described in https://uefi.org/sites/default/files/resources/7_Maciej%20Vincent_INTEL_network%20stack%20performance.pdf with code at https://github.com/tianocore/edk2-staging/tree/MpNetworkStack. Perhaps a similar grafting could be done w/ something like smoltcp (versus lwip) and the rust bindings work you've been enabling? Vincent -----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Michael D Kinney Sent: Friday, December 9, 2022 10:12 AM To: Ayush Singh <ayushdevel1325@...>; discuss@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...> Cc: Michael Kubacki <mikuback@...> Subject: Re: [edk2-discuss] Clarification about UEFI networking stack Yes. MNP is the lowest network stack layer that is guaranteed to be present for every Network Device. This link to one section earlier describes the options for Network Device vendors. They can choose to implement UNDI, or SNP, or MNP. If they choose UNDI, then that platform can produce SNP and MNP for the network device. If they choose SNP, then the platform can produce MNP for the network device. https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines Best regards, Mike From: Ayush Singh <ayushdevel1325@...> Sent: Friday, December 9, 2022 10:04 AM To: discuss@edk2.groups.io Cc: Kinney, Michael D <michael.d.kinney@...>; Michael Kubacki <mikuback@...> Subject: Clarification about UEFI networking stack Hello everyone, I am thinking about writing better networking for UEFI Rust development. As such, I was trying to understand the relation and availability of UNDI/NII, SNP, MNP, TCP protocols, etc. What would be the best protocol to base the networking stack on? From this [1] documentation I found, it seems that as long as SNP is implemented, MNP will be layered on top of SNP by firmware. So can I assume that at least MNP will almost always be available if networking is present in any form? Yours Sincerely Ayush Singh [1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines/252_nii_protocol_and_undi_implementations |
|
|
|
Well, most of my prior work was focused on implementing Rust std for UEFI
targets [1] in upstream Rust, which is still a work in progress, so it might be a while before I can work on integrating Rust in edk2 build process. I have already upstreamed most of the changes needed in std (like custom entry and stuff), so it's going pretty well. Also, I moved the allocator out of std into a separate crate, r-efi-alloc [2], so that it can be used without std. I did try to begin some work by cleaning up edk2-basetools [3], but I never got any feedback, and then I had exams, so it kinda fell off. I might try doing something about it again now that I have a vacation, but I'm not sure how I should approach it to get some feedback. Yours Sincerely Ayush Singh [1]: https://github.com/rust-lang/rust/pull/100316 [2]: https://github.com/r-efi/r-efi-alloc [3]: https://github.com/tianocore/edk2-basetools/issues/57 On Sat, Dec 10, 2022 at 5:32 AM Zimmer, Vincent <vincent.zimmer@...> wrote: A rust-based stack for edkII would be interesting. |
|
|