[RFC] svd2rust workspace generation
#338
Conversation
|
CC (especially) @japaric, @rust-embedded/tools. |
| The usage of modules `ethernet`, `spi` and `wom` would then only differ by their top-level import name. | ||
|
|
||
| ```rust | ||
| use acme_mcu8008::{ethernet, spi, wom}; |
There was a problem hiding this comment.
Presumably today's Peripherals singleton struct which contains all peripherals will live in this crate. If one does not want to use that crate to get faster compile times how do they get an instance of say USART1? Will USART1 gain a take static constructor whose implementation contains a static ONCE: bool to prevent getting several instances of the same peripheral / singleton? That would use more RAM than today's implementation and should be noted.
|
|
||
| ## Rationale and alternatives | ||
|
|
||
| An alternative to generating multiple crates for peripherals was to generate feature flags for each peripheral, |
There was a problem hiding this comment.
Perhaps mention here that both approaches lead to same amount of code being compiled but this proposal has the advantage of parallel compilation of peripheral code. It would be interesting to have numbers on how much parallel compilation helps with overall compile times.
|
|
||
| ## Unresolved questions | ||
|
|
||
| A HAL crate could potentially have dozens of peripheral sub-crates. |
There was a problem hiding this comment.
For the record I have been contacted by the docs.rs team before because svd2rust crates were clogging the build queue so they ended up disabling doc generation for targets other than Linux (normally, cargo doc is run on your crate several times to generate docs for Linux, Windows, macOS, etc.) on these crates to reduce the build times.
I wonder if sequentially building docs for 50 crates w/ 20K LoC each takes longer than building the docs of a single crate w/ 1M LoC.
|
At stm32-rs we build svd2rust crates for all STM32 devices, factoring out the common changes to svd files to help reduce duplication of effort. The svd2rust output is turned into a single module per device, and then all devices belonging to the same family are published as part of the family crate. For example, the stm32f405 device is a module in the stm32f4 crate, which is on crates.io. This means there's 11 crates which is already a fair amount to manage -- even with a script publishing them sequentially, it takes some time to publish and then docs.rs takes a real hit each release. In fact we only generate documentation for one or two devices per family to avoid overloading docs.rs. Overall we have 48 devices so far, and in total over 1500 peripherals, so with this change we'd go from 11 crates to >1500, just for this project. I think it would take it beyond manageable even with automation -- that would be over 6% of all of crates on crates.io! I totally get wanting to reduce compile times, but for the family projects like stm32-rs I don't think a crate per peripheral is the way to go, if anything I'd like to see built-in support for generating fewer crates. Ideally I'd just have a single stm32-rs crate with every stm32 supported and all the common peripherals automatically factored out! Perhaps if this is added it could be an optional switch, so at least stm32-rs could keep doing what it does? I like feature-gating the peripherals as a way to reduce compilation times without parallelism and it seems like feature gates would also integrate well with HAL crates providing feature-gated implementations per peripheral. The additive nature of features works perfectly with this approach too. |
As previously discussed at the Rust All-Hands 2019 in Berlin,
this RFC proposes to change the way that
svd2rustgenerates platform crates,away from peripheral modules to peripheral sub-crates.
Rendered version