-
-
Notifications
You must be signed in to change notification settings - Fork 178
uefi-raw: improve convenience of net types #1699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2b8f102 to
85838ce
Compare
For the record. Starting Friday, I'll be on vacation until July 30th. My plan is to program-detox for the whole period 😀 Restarting the work afterwards
85838ce to
1b7a7be
Compare
1b7a7be to
2ecc76c
Compare
2ecc76c to
a76f20e
Compare
a76f20e to
1f7cd1b
Compare
I'm unsure how I could fix the rustdoc error best. I want the documentation of the net module to be publicly available (it is a clear value-add), but earlier you suggested exporting its exports in a flat way, i.e., directly from the top-level.
However: making the module public allows to import the same types from uefi_raw::Type and uefi_raw::net::Type, which is not ideal. Perhaps we should export all net::* types also publicly?
What if we removed the module doc and instead added this information to the individual types? The module doc is basically saying "you can convert between core::net types and uefi_raw net type". E.g. for Ipv4Address it could be something like:
/// An IPv4 internet protocol address. /// /// This type can be converted to and from [`core::net::Ipv4Addr`] using the [`From`] trait.
c2d44b0 to
24d5443
Compare
What if we removed the module doc and instead added this information to the individual types?
Yeah, good idea, why not :) What do you think about the latest state?
411d16e to
f2b5198
Compare
Generally looks good, but I haven't reviewed the details yet. Could you open a PR that just does the copy-paste move of stuff to a new module first? That should be very quick to review and merge, and then it won't get mixed in with the other changes. (I realize it's already broken down that way by commit, but there are still a lot of changes in commit 870aced that I would like to review more thoroughly, and it'll be easier for me if the module-move has already been merged.)
aa1b362 to
4261a10
Compare
This will help in the following to better distinct between all the types from core::net (Std prefix) and EFI (no prefix).
4261a10 to
0d4fe50
Compare
should be much easier to review now
- added missing conversions between core::net types and the uefi-raw net types - added missing conversions for "typical byte arrays"
0d4fe50 to
3bfe5a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about an associated const instead of a function?
pub const ZERO: Self = Self { addr: [0; 4] };
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I guess this is a personal preference thing, but I don't think it's clearer to introduce type aliases for the core::net types. core::net:: isn't that long to write out, and is more explicit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you say more about why this is desired? Perhaps a specific example of code where it would be useful to have this property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a method is needed when it's just returning a pointer to self, instead the caller can write &raw addr/&raw mut addr (those operators were stabilized in 1.82)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was removing MacAddress -> [u8; 6] intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to make an assumption about zero being invalid, but is that true? If so, let's point to relevant documentation. If not, let's drop this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This is a bit ambiguous. "all underlying bytes" could be read as "all bytes in the type", but that's not required for ipv4. Maybe something like: "Callers must ensure that the v4 field is valid if is_ipv6 is false, and that the v6 field is valid if is_ipv6 is true"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Should this be into_core_ip_addr? I'm not sure if there's an existing ecosystem convention either way, just want to make clear to end users that this method works in a no_std env.
Uh oh!
There was an error while loading. Please reload this page.
This prepares my vision for #1575, a split-out from #1645.
This adds much more convenience to the network types in
uefi-raw, better integrating them withcore::nettypes but also "typical" workflows. This "higher-level" logic is still low-level enough that I think it is perfectly fine to keep it. It will also not hinder Rust-based UEFI implementations.Steps to Undraft
Checklist