<adamgreig[m]>
sadly busy work weeks correlate with quiet rust weeks 😅
<adamgreig[m]>
impossible deadline is meeting immovable necessity
<bartmassey[m]>
Yeah, I'm reviewing that PR now, but would love help. Not sure if it belongs in the nomicon, but sure that we want it somewhere.
<bartmassey[m]>
There's a lot of good stuff there.
<therealprof[m]>
bartmassey[m]: I think we supported that idea in Utrecht and even encouraged putting it there.
<bartmassey[m]>
Excellent. I will proceed on that basis.
<bartmassey[m]>
Author also has more stuff that isn't in the PR. Really welcome.
<jannic[m]>
I didn't read it yet, but from a quick look it seems to be quite self-contained. If we decide there's a better place later, it'll be easy to move.
<bartmassey[m]>
Yes indeed.
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
love the idea, and from a quick read it would be awesome for vendors to follow the guide laid out
<therealprof[m]>
Reading that, I think we had a bit more lowlevel info in mind but I don't hate it. Just curious whether the nomicon provides the visibility it deserves.
<bartmassey[m]>
therealprof: Those were more-or-less my thoughts as well… But you talked me out of them above. 😀
<therealprof[m]>
bartmassey[m]: Fair.
<bartmassey[m]>
Anyway, for now let's just take the PR in the Nomicon once one or two others and I have had a chance to review it. Don't want to lose it for sure. Thanks adamgreig for the reminder.
<adamgreig[m]>
sounds good
<adamgreig[m]>
there's a few points from triage (thanks jannic) maybe starting with https://github.com/rust-embedded/svd2rust/pull/933 about whether to bump svd2rust generated code to support edition 2024
<therealprof[m]>
Is there any obvious benefit of going 2024?
<rmsyn[m]>
+1 for bumping
<rmsyn[m]>
therealprof[m]: taking advantage of new lints + stabilized features
<therealprof[m]>
Yeah but in PACs?
<jannic[m]>
Do lints help much for generated code?
<rmsyn[m]>
in the generation of PACs*
<bartmassey[m]>
Could/should we put conditional compilation in based on edition? It would be a bit ugly, but could work I guess…
<rmsyn[m]>
jannic[m]: it helps for the code generator
<therealprof[m]>
bartmassey[m]: Please lets not.
<bartmassey[m]>
?
<jannic[m]>
rmsyn[m]: I think that's independent, the code generator can use edition 2024 and still generate code for edition 2021.
<therealprof[m]>
rmsyn[m]: As adamgreig put it, this is about bumping the generated code to 2024, not svd2rust.
<adamgreig[m]>
I think the relevant changes are all things it makes sense to do in the generated code
<adamgreig[m]>
it's mostly around adding unsafe in places the compiler now requires it
<rmsyn[m]>
therealprof[m]: right, after re-reading I realized that 😅
<therealprof[m]>
adamgreig[m]: Yeah, but that's just cosmetics without any real benefits, no?
<bartmassey[m]>
I'm just worried about old crates that directly use svd2rust and then try to build the result with edition=2021.
<rmsyn[m]>
maybe adding an additional flag for `--edition` would be useful?
<bartmassey[m]>
That's what I was thinking.
<bartmassey[m]>
The default would probably have to be 2021, but that's ok.
<adamgreig[m]>
is there much point? having to support emitting multiple editions seems like a lot of extra work and testing
<adamgreig[m]>
if there's not enough interest in supporting 2024 edition it seems better to stick to 2021 until there's something we really want
<therealprof[m]>
bartmassey[m]: Those exist? I only know of cases where the PAC is separate from the "HAL" and those can use different editions.
<therealprof[m]>
adamgreig[m]: That's what I'm thinking.
<adamgreig[m]>
but I don't think it's likely to be a major compatibility hazard anyway
<bartmassey[m]>
IDK what exists. It certainly isn't common: normally people work from svd2rust output for sure.
<adamgreig[m]>
you'd have to update to a new svd2rust to get the new generation, at which point when you next generate the pac it will compiler-error until you also bump the pac edition
<therealprof[m]>
If there's some noticeable effect, like much faster compile time, then sure...
<adamgreig[m]>
still, if there's no functional benefit I don't mind leaving it as requiring edition 2021 for now
<bartmassey[m]>
Maybe just stick a deliberate cfg in the generated code now that checks for edition="2024"?
<bartmassey[m]>
At least that way people would notice if their stuff borked.
<adamgreig[m]>
thejpster[m]: ah, good to know, that's a fairly compelling reason to not require it yet
burrbull[m] has joined #rust-embedded
<burrbull[m]>
There is still static mut DEVICE_PERIPHERALS. Can it block upgrade to 2024?
<adamgreig[m]>
i assume at some point we'll really want to do 2024 edition, and i assume at some point ferrocene will probably support it
<adamgreig[m]>
static muts still work in 2024 in the end
<thejpster[m]>
Why is it doing static mut?
<jannic[m]>
BTW the sentence "Should we bump rust to 1.82 and fix this or stay on edition 2021" in the ticket is a bit misleading, we need 1.85 for edition 2024
<adamgreig[m]>
thejpster: this is the static it uses to prevent multiple PACs being linked together
<bartmassey[m]>
I think either a flag for svd2rust (easy) or a bunch of ifdefs for 2021/2024 is the right plan, but I'm easy with whatever.
<adamgreig[m]>
* thejpster: this is the static it uses to prevent multiple PAC versions being linked together
<adamgreig[m]>
(from before links= existed in cargo.toml)
<rmsyn[m]>
bartmassey[m]: is conditional compilation on edition even possible? I know that a third-party crate is needed for compiler versions. is edition in a similar situation?
<bartmassey[m]>
Actually, take back "(easy)" above. It would also be a pain.
<jannic[m]>
IIRC edition 2024 doesn't forbid static mut, but only references to static mut.
<adamgreig[m]>
I have to run, sorry! it sounds to me like we could most easily just stick with 2021 edition and wait til there's a compelling reason to want 2024, at which point it's probably easier to swap over to it wholesale, but supporting bath in parallel sounds like a lot of work for minimal gain atm
<thejpster[m]>
Given the code is auto generated, and given code from any edition will link together nicely what does Edition 2024 gain the user of the PAC?
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
thejpster[m]: This is a great reason to wait before moving to edition 2024, I guess
<adamgreig[m]>
hopefully I'll be OK to run the meeting next week but even odds I'll have to run early again if so
<bartmassey[m]>
Thanks as always!
<adamgreig[m]>
thejpster: right, nothing, it only benefits us if there become features we want to use in the generated code that require it
<thejpster[m]>
romancardenas[m]: Ferrocene is an LTS so you don’t just need a new one to exist, you need everyone to move to it, and change their certification processes to support the new edition. It’s not easy.
<thejpster[m]>
adamgreig[m]: So I’d say bring me a compelling use case and then we can think about it.
<rmsyn[m]>
thejpster[m]: would this be a years-long effort?
<thejpster[m]>
Further, I’d say “maybe it should generate edition 2018 compliant code by default”
<therealprof[m]>
thejpster[m]: zing....
<bartmassey[m]>
Why not 2015?
<thejpster[m]>
I’m much more concerned with the output being Actually Unsound because it still creates references to MMIO space.
<rmsyn[m]>
we're already four years out from 2021, though...
<thejpster[m]>
bartmassey[m]: Why not.
<rmsyn[m]>
because that locks into an ancient edition
<bartmassey[m]>
I suspect that anytime before inline assembly became stabilized would be a bit unpleasant? But I haven't looked much at the generated code.
<rmsyn[m]>
literally a decade old
<thejpster[m]>
Points at K&R ANSI C edition
<rmsyn[m]>
I understand that the compliance work (paperwork / bureaucracy stuff) can take forever, but the code should move much, much quicker
<rmsyn[m]>
why inherit the worst parts of C toolchains into Rust?
<bartmassey[m]>
thejpster: Agree about Actual Unsoundness. We've talked about fixing that before, but can't remember what the plan was?
<Ralph[m]>
<adamgreig[m]> "those are just "popular reposito..." <- ah, you're right! i'm so used to always seeing pinned repos that i totally missed the fact that there are orgs/users where the repos aren't pinned 😅
<Ralph[m]>
but yeah, i'd suggest pinning some repos (e-h & wg being the obvious ones, probably also heapless and maybe the book(s)?)
<thejpster[m]>
One person’s “bureaucracy stuff” is another person’s “so many people have died already, we need to do things better”. Opinions vary.
<thejpster[m]>
As do use cases.
<bartmassey[m]>
I thought it was replacing all the references with pointers, but who was going to do that when / how?
<rmsyn[m]>
thejpster[m]: right, but the paperwork + checkboxing lags behind the actual code + tooling that ensures less people die
<bartmassey[m]>
Ralph: TBH I didn't realize there was repo pinning until now. Will pin some stuff shortly.
<bartmassey[m]>
Suggest we all agree to disagree about the general issue of safety process. It sounds like we have decided not to accept the PR for now. What do we tell submitter?
<bartmassey[m]>
Also, let's add reviving the Actual Unsoundness issue to next week's agenda?
<therealprof[m]>
bartmassey[m]: I left a comment.
<bartmassey[m]>
Thank you!
<rmsyn[m]>
bartmassey[m]: I'm not trying to be argumentative here. I have much less experience than @thejpster:matrix.org regarding safety-critical stuff. I would defer to @thejpster:matrix.org regarding anything regarding that domain. just voicing my opinion on not wanting the `svd2rust` PACs to get stuck on certain editions, especially ones that have been around for years. maybe bleeding edge isn't appropriate, but I also think going to a
<rmsyn[m]>
decade old edition is too far in the opposite direction
thenightmail has quit [Changing host]
thenightmail has joined #rust-embedded
<therealprof[m]>
rmsyn[m]: Maybe the remark shouldn't be taken too seriously? 😉
<rmsyn[m]>
s/regarding/rin/
<rmsyn[m]>
s/regarding/in/
<bartmassey[m]>
I certainly didn't intend my remark on this seriously. At all. 2015 is far behind us now.
<bartmassey[m]>
And in any case, it probably doesn't make sense to make the default an Edition that precedes the creation of svd2rust 😀
<bartmassey[m]>
@jannic Thanks as always for the triage. Please re-raise the unaddressed ones next week!
<bartmassey[m]>
I'm definitely open to something like this, if someone wants to put in the work. I doubt it would be hard to maintain once created. We could ask the original PR author if they want to take it on, I guess.
<bartmassey[m]>
Looks like I can't pin repos on the Rust Embedded organization because insufficient permissions. Only repo owners or something.
<Ralph[m]>
i'm not involved with `svd2rust` & co., but: aren't there already now _too many_ such tools (`svd2rust`, `chiptool`, `raltool`, and `svd2pac` from what i just read i the other PR 🙂) which all do the same? does it really make sense to split it _even more_?
<Ralph[m]>
(i'll happily use HALs and haven't had to get my hands dirty (yet) with generating PACs - just wanted to point this out as i think i recall having read lately some discussion about whether it's time to start unifying this again?)
<bartmassey[m]>
Somebody should probably at least fix the book link in the README.md at github.com/rust-embedded to point to the new Discovery book instead of the old one.
<therealprof[m]>
bartmassey[m]: I don't see it?
<rmsyn[m]>
Ralph[m]: a number of those tools split off from `svd2rust`, but I think `svd2rust` is seen as the "blessed" tool in the ecosystem. since ferrocene is also a critical piece of the ecosystem, I think it makes sense to seriously consider its requirements regarding tools like `svd2rust`. other tools in the ecosystem are free to do whatever they want
<bartmassey[m]>
therealprof: It's the link labeled "Embedded Rust book" in "Check out our embedded Rust book…"
<therealprof[m]>
<bartmassey[m]> "Looks like I can't pin repos..." <- Which would you think we should pin, that number is rather limited to 6 or so.
<therealprof[m]>
bartmassey[m]: That's pointing to "the" book though, not the discovery book.
<bartmassey[m]>
therealprof: Ah, I misread the link. Apologies. Should we point to that book? I'm not sure of its status: I haven't spent much time with it.
<bartmassey[m]>
Not sure what actual code repos we should pin. The ecosystem is pretty diffuse.
<bartmassey[m]>
awesome-embedded-rust probably
<therealprof[m]>
bartmassey[m]: Yes, we should. It's not too bad, explains the idea of embedded programming and Rust abstractly.
<bartmassey[m]>
Maybe rust-embedded.github.io.
<Ralph[m]>
bartmassey[m]: i'd probably pin the `embedded-hal` - it's a pretty central thing
<bartmassey[m]>
Maybe put the Disco book in the README also?
<bartmassey[m]>
Ralph: Absolutely. And we're at 6 unless people disagree.
<Ralph[m]>
bartmassey[m]: i think the link for that should be in the README but the repo shouldn't be pinned - after all, that repo is just technical infrastructure and few people browsing the WG project do so to explicitly modify the website
<bartmassey[m]>
Fair enough.
<bartmassey[m]>
therealprof: Want to pin the other 5 for now? We can always change stuff later, but it's a start.
<therealprof[m]>
Already made all the changes you had suggested in the meantime. 😉
<therealprof[m]>
Luckily we're all in line. 😉
<therealprof[m]>
I added the discovery book, and pinned the most critical ressources (AER, the books, e-h and cargo-binutils).
<Ralph[m]>
thanks!
<Ralph[m]>
i just browsed the repo list (i _really_ should be doing other things... but you know how it is if you should be doing something you don't really feel like doing? 😅) and just learnt, that there's a "showcase" repo: https://github.com/rust-embedded/showcase
<Ralph[m]>
(probably from when the WG was created? it's from 2018)
<Ralph[m]>
note to self: stop looking at old repos in orgs you're not a maintainer 🤣)
<bartmassey[m]>
Thank you much for all this! Please post it in the agenda for next meeting, and we'll get consensus and deal with it all. We've talked about some of it before; it shouldn't be hard to fix.
<therealprof[m]>
<Ralph[m]> "and further browsing has shown..." <- Yes, we have a sponsor for those sites and a few domains. They all predate the usability of GH pages, I don't remember why we kept them there, though.
<therealprof[m]>
We said we'd probably keep the showcase, and no, it doesn't really conflict with AER, but we might want to put fresh projects on there.
richardeoin has quit [Quit: WeeChat 4.1.1]
<Ralph[m]>
<bartmassey[m]> "Thank you much for all this..." <- done 👍️
<Ralph[m]>
therealprof[m]: it might be nice to have some real-world commercial examples on there as well (e.g. dirbaios door locks) to show to the world that this isn't just a hobbyist thing
<bartmassey[m]>
Yes, let's freshen it or archive it; having it dead is worse than either.
<bartmassey[m]>
And yes, let's get it off AWS if someone is paying for it.
<bartmassey[m]>
Anyhow, we'll talk next week.
richardeoin has joined #rust-embedded
<therealprof[m]>
<Ralph[m]> "it might be nice to have some..." <- That was the idea behind the showcase, yes.
kevlan[m] has joined #rust-embedded
<kevlan[m]>
James Munns: had put together a big list recently of companies and projects using embedded rust. That could be a starting point for building out the showcase site.
thalesfragoso[m] has quit [Quit: Idle timeout reached: 172800s]
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
<JamesMunns[m]>
Feel free to copy and paste as much as you want from that article. if anyone wants the raw markdown, or wants me to +1 using it, happy to provide it
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
<JamesMunns[m]>
Feel free to copy and paste as much as you want from that article. if anyone wants the raw markdown, or wants me to +1 using it, happy to provide it