You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the API for creating a ProtectiveMBR is somewhat unclear, or at least easy to misuse. While the documentation does explain that the input should be the number of logical blocks not including the PMBR, the naming and much around this is unclear.
Specifically, the lb_size term is overloaded. On GptConfig, you have logical_block_size which expects a gpt::disk::LogicalBlockSize value. lb_size itself is set to be a gpt::disk::LogicalBlockSize in many of the tests and documentation.
let mbr = gpt::mbr::ProtectiveMBR::with_lb_size(<blah>); // Wants size _in_ Logical Blocks, not size _of_ Logical Block
The text was updated successfully, but these errors were encountered:
I think it makes sense to clear up these functions by moving the lb part of the function name to its signature through the introduction of a LogicalBlockLength type, as a counterpart to the LogicalBlockSize enum.
Maybe even just a Blocks(u32) tuple struct.
For the record, I find the fault here to be more with the EFI spec. The confusion there is real when it comes down to the implementation side of things.
Currently the API for creating a ProtectiveMBR is somewhat unclear, or at least easy to misuse. While the documentation does explain that the input should be the number of logical blocks not including the PMBR, the naming and much around this is unclear.
Specifically, the
lb_size
term is overloaded. OnGptConfig
, you havelogical_block_size
which expects agpt::disk::LogicalBlockSize
value.lb_size
itself is set to be agpt::disk::LogicalBlockSize
in many of the tests and documentation.The text was updated successfully, but these errors were encountered: