Add structs for all device path node types and a new DevicePathBuilder
#547
Conversation
nicholasbishop
force-pushed
the
bishop-build-device-path-codegen-12
branch
2 times, most recently
from
16c7bbf to
866daef
Compare
|
Thanks for the amazing effort to finish the addition of device path node types! There was some discussion in the past about using automatic code generation to cover more of the UEFI spec, but this is the first concrete implementation of the idea. |
nicholasbishop
force-pushed
the
bishop-build-device-path-codegen-12
branch
from
866daef to
ee6b57b
Compare
See xtask/src/device_path/README.md for details of the design. The actual generated code is added in the following commit.
The `device_path` module now exposes the generated submodules containing all the packed node types. The `device_path::build` module contains `DevicePathBuilder`, which allows for constructing new device paths. It also exposes the generated submodules containing all the builder node types.
These have been replaced by the generated types in `device_path_gen.rs`.
nicholasbishop
force-pushed
the
bishop-build-device-path-codegen-12
branch
from
ee6b57b to
67df1eb
Compare
| compilation-time drawbacks. It also introduces a new problem: `build.rs` | ||
| may not integrate well with non-cargo build systems. | ||
|
|
||
| That brings us to the solution actually implemented here, which is to |
|
Thanks for putting all the effort into this! Awesome!
My knowledge regarding this part of the UEFI spec is very limited. But what I see looks very good! |
|
Can someone give me please a high-level description in 2-3 sentences about what device path nodes are and especially where they are useful? When does an UEFI-application developer needs them? @nicholasbishop @GabrielMajeri |
|
I have a brief page in the book that tries to explain a bit, although it could definitely benefit from some more concrete examples: https://rust-osdev.github.io/uefi-rs/HEAD/concepts/device_paths.html You can think of device paths as kind of like a different take on the Unix view of "everything is a file mounted somewhere under Device paths can be helpful for distinguishing between handles and understanding their relationship. For example, all partitions on all disks attached to the system could have handles that support the BlockIO protocol. By looking at the common parent nodes in the associated device path, you could figure out which partitions are on which disk. Hopefully that helps a bit clarify a bit :) |
|
Very informative, thank you! :) |
There are over 50 device path node types in the spec, of all shapes and sizes. Previously we just had support for three of them, and even for those we only supported reading them, not building new ones. This PR fixes that but it takes a fair amount of code -- apologies for the rather large PR :)
A lot of the code is generated; see
xtask/src/device_path/README.mdfor an overview of why and how.Fixes #401
Fixes #420
Checklist