<Ralph[m]>
but since `defmt` is now stable and unlikely to break again any time soon i guess it doesn't hurt to just keep the dependency and instead start using it again? (and while it shows >3k downloads on crates.io (people are actually using my stuff?!) that's also not that many consumers, so releasing v2.0 of this crate wouldn't be the end of the world)
<Lumpio->
If it's "completely unused" what breaks if you remove it? The fact that the feature isn't available anymore?
<Lumpio->
Is it possible to add a dummy feature as a patch release
<Lumpio->
remove the dep + add dummy feature with a deprecation notice
<Ralph[m]>
ah, true, dummy feature would work as well and make it non-breaking. though i think actually keeping it and instead offering defmt support for the error might be nicer. otherwise consumers need to deal with that
<Ralph[m]>
<Ralph[m]> "any opinions on how to deal with..." <- for now i've decided to keep the dependency and instead use it again. with the anticipated stability of `defmt` i don't see any issue with that
<thejpster[m]>
in a weird co-incidence, I'm also on a podcast tomorrow, talking about Rust, and I am making studious notes for when the "So who's using Rust?" question comes up.
<adamgreig[m]>
ok, let's begin! I've not got any announcements this week, but a couple of quick points first: robamu has volunteered to join the Arm team to help with cortex-ar maintenance (https://github.com/rust-embedded/wg/pull/831) so Arm team members should please have a look and comment or vote there
<adamgreig[m]>
and second, James Munns do you want to say anything about collecting embedded use cases?
<JamesMunns[m]>
Yep! @thejpster are on the PR tour (as always), I thought it would be good to have a list of known-embedded-rust products/users
<JamesMunns[m]>
I've been informally posting them as I get them on my bluesky, I'm going to put them all into a blog post afterwards for future reference
<JamesMunns[m]>
Feel free to put them here, on the meeting notes, on bluesky, send me a DM, wherever :)
<thejpster[m]>
and generally lament the lack of reviewbot on our repos
<thejpster[m]>
it's never clear who I should ping for a review
<adamgreig[m]>
frustrating that it's easier to use windows in ci to run qemu 9 than to get qemu 9 for ubuntu
<JamesMunns[m]>
We're setup with the `team` repo, I wonder if we could get the Rust review bot for our space?
<thejpster[m]>
yeah tell me about it.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
JamesMunns[m]: "our space"?
<JamesMunns[m]>
for the rust-embedded github org repos
<adamgreig[m]>
we can and have got hifivebot on our repos
<adamgreig[m]>
or triagebot?
<thejpster[m]>
this also makes the assumption that everyone on the team is happy to be in review rotation
<adamgreig[m]>
but I would say it's not been the most effective thing for that reason, yea
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Can't just build QEMU from source on Ubuntu easily? That's what I've done in the past on Debian.
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
adamgreig[m]: Maybe with nix?
<JamesMunns[m]>
Should we start making a push to look for more volunteers to join the wg?
<adamgreig[m]>
for cortex-ar it's probably better to specifically ping someone who's been helping with cortex-ar maintenance
<JamesMunns[m]>
and make it easier for interested folks to join?
<thejpster[m]>
> Can't just build...
<thejpster[m]>
If it was that easy I'd have done it. You're welcome to try it out and send a PR!
<JamesMunns[m]>
like - make it a priority, keep member PRs as a standing meeting item for the next bit?
<thejpster[m]>
cough Arm cough
<thejpster[m]>
I like the idea of a standing item.
<thejpster[m]>
Technically we have a triage team who make sure no PR gets left behind.
<JamesMunns[m]>
Maybe we also do our regular GC pass of "hey you still there and interested" for existing members?
<thejpster[m]>
that would be good too.
<thejpster[m]>
helps with quorum
<bartmassey[m]>
thejpster: Fair enough. I doubt I'll have time to poke at it in the short run, but I'll try to get to it eventually.
<JamesMunns[m]>
Happy to put together a standing tracking issue if we want to start discussing, and add it to the agenda next week.
<adamgreig[m]>
sounds OK to me, it's been a long time since we've polled members to check they're still active and interested in helping
<JamesMunns[m]>
adamgreig[m]: yeah if anyone finds that issue, lemme know, it feels like between 12 and forever months ago
<JamesMunns[m]>
probably good to do 1-2x/year
<thejpster[m]>
bartmassey: I think it'll only work if you can find somewhere to stash the binary so you don't have to keep building it. Otherwise I suspect it'll be 5 minute dependency install and then a 15 minute QEMU build to run a 3 minute test. And on Windows, you can just grab the binary and you're done.
<thejpster[m]>
pick who will be our beneficent overlords for the coming year
<thalesfragoso[m]>
thejpster[m]: nixpkgs has qemu 9 btw
<therealprof[m]>
thejpster[m]: Interested?
<thejpster[m]>
I'll do a lot of things, but I'm not touching a nix PR.
<thejpster[m]>
therealprof[m]: no
jannic[m] has joined #rust-embedded
<jannic[m]>
<thejpster[m]> "Technically we have a triage..." <- I try to look through the repos every now and make sure nothing gets lost, but I got the feeling it's not too effective to present a list of open PRs in every meeting.
<adamgreig[m]>
jannic: fwiw, I really appreciate the issues you flag up in meetings, I feel like they do often (but not always) then get attention/resolved in the meeting
<bartmassey[m]>
TBH one or two open PRs per meeting seems good to me.
<adamgreig[m]>
but yea, probably doing every open issue and pr every meeting isn't going to get far
<thejpster[m]>
bartmassey[m]: only if they get a jingle. Now time for Janni's Top Two! dah dah duh duh dun duuuuuuu
<thejpster[m]>
s/Janni/Jannic/
<jannic[m]>
It also depends on the right people being available. Not everybody knows every repo well enough to do a good review.
<therealprof[m]>
Japanese train line music. 😉
<JamesMunns[m]>
jannic[m]: I wonder if it makes sense to put some effort into establishing CODEOWNERS for various repos and parts of repos?
<jannic[m]>
But thanks for the feedback. I'll try to select some tickets more regularly.
<therealprof[m]>
therealprof[m]: Reminds me: I won't be here the next two weeks due to being in said country.
<JamesMunns[m]>
therealprof[m]: Safe travels!
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
jannic[m]: yeah, I can confidently handle reviews on RISC-V and tools related stuff, outside of that I would need to do a lot more work to get up to speed
<adamgreig[m]>
JamesMunns[m]: last time I think we had a github teams chat (though I think this no longer exists) to ask people to report in if they were still happy to be involved
<adamgreig[m]>
not sure what the best method would be now - an issue with tickboxes?
<adamgreig[m]>
it's hard to actually see who ticked each box when there's that many though
<adamgreig[m]>
JamesMunns[m]: shouldn't this basically just be the responsible team, or are you thinking of splitting up to individuals for parts of/whole repos?
<adamgreig[m]>
it probably makes practical sense
<JamesMunns[m]>
I think there's some split to be had, for example embedded-hal, not all members are totally comfortable with async, I imagine
<adamgreig[m]>
therealprof[m]: have a good trip!
<JamesMunns[m]>
but in most case, I think starting with the teams, and massaging from there isn't a bad call
<jannic[m]>
With git it's also easy to see who worked on that code in the past. That's usually a good indication for a qualified reviewer.
<adamgreig[m]>
so long as they're still around :P
<jannic[m]>
Yes. And not the same person who sent the PR to be reviewed.
<thejpster[m]>
I'd like to talk about Tiers next
<adamgreig[m]>
sure, go for it
<adamgreig[m]>
specifically for the v8r target or more generally?
<thejpster[m]>
yeah
<thejpster[m]>
for armv8r-none-eabihf specifically
<thejpster[m]>
1. Do we want to?
<thejpster[m]>
2. Who wants to write it up? (I cannot)
<thejpster[m]>
3. Do we want the Arm team to be the maintainer? What about Chris who is the current maintainer?
<bartmassey[m]>
Sounds like include Chris on Arm team and make it the maintainer?
<adamgreig[m]>
if Chris is happy to continue being the maintainer, is there any reason for us to step in?
<thejpster[m]>
consistency?
<thejpster[m]>
why would the EDWG maintain some bare-metal arm targets and not others?
<thejpster[m]>
nothing against Chris. He's great.
<bartmassey[m]>
I think we want to do this. Seems like you have the rationale pretty well figured out already. What more writeup would we need?
<thejpster[m]>
and he wants to continue, and I'm happy to let him.
<adamgreig[m]>
we maintain some because no-one else was there to maintain them and they needed maintainers to keep them at tier 2
<bartmassey[m]>
Sounded like he wanted to join the Arm team? Or am I confused?
<thejpster[m]>
you could make an argument for the EDWG being the de-facto owner of all the -none-targets. If you really wanted to.
<thejpster[m]>
he did, but also wanted to retain his individual credit as maintainer
<adamgreig[m]>
I'm not saying we'd be a bad choice as maintainer, but wonder if there's any practical difference to having us added in this case. I'm happy for it to happen.
<bartmassey[m]>
My vote doesn't count for much, but I would be fine with both of these.
<bartmassey[m]>
I don't think it matters much whether EDWG or Chris is listed as maintainer, as long as everyone understands that we are a fallback if Chris steps away.
<thejpster[m]>
"stop the world, this tier 2 target isn't building and it's blocking a release" just seems like a lot to pin on specific unpaid individuals. But I'm not here to fix the whole target maintainer system.
<thejpster[m]>
anyway, if someone wants to open the PR to upgrade it, please do. I won't.
<thejpster[m]>
but it is very annoying that we can't test cortex-ar on stable.
<bartmassey[m]>
Maybe Chris could PR it?
<bartmassey[m]>
(gtg class :frowning: :wave:)
<thejpster[m]>
<adamgreig[m]> "we maintain some because no-..." <- does this imply we should be seeking individual maintainers to relieve us of our backstop position?
<adamgreig[m]>
hmm, I don't think so?
<adamgreig[m]>
more that if the target already has an active individual maintainer then we don't have the same urgent impetus to take over (but I think are happy to)
<adamgreig[m]>
<thejpster[m]> ""stop the world, this tier 2..." <- yea, nice to have some more people to spread it over (though the teams are themselves just some more unpaid individuals)
<adamgreig[m]>
does us being maintainer have any bearing on the target getting promoted to tier 2?
<therealprof[m]>
I think it doesn't make any difference.
<thejpster[m]>
I don't think it would materially affect the proposal, provided it was supported by the current maintainer
<adamgreig[m]>
OK. I think I'd like to go with what Chris feels: if he's keen for the arm team to be added as a maintainer and would welcome the extra line there, let's have a vote on the arm team and assuming it's a yes I can file a PR on rust to add us as maintainer
<adamgreig[m]>
I think separately it makes sense to push for tier 2, but you don't want to do that yourself? is chris interested in that?
<thejpster[m]>
I can ask Chris if he wants to push it
<adamgreig[m]>
that would be great, thanks. and if he'd be keen for the arm team to be added as a maintainer or is happy to stay the only maintainer with the knowledge we could probably take it on if he wanted later.
<thejpster[m]>
looking at that list ... is it worth just doing armv7a-none-eabihf at the same time? For anyone doing bare-metal Arm Cortex-A7 or something else that isn't AArch64?
<thejpster[m]>
Like, Motorola 68000 I think we can live without for now
<thejpster[m]>
also, weird there's no thumbv8r-none-eabihf target for Armv8-R running in Thumb mode. Pretty sure it supports Thumb mode.
<i509vcb[m]>
I'd certainly like to meet anyone who is using 68000 in production in 2025
<adamgreig[m]>
does that require a separate target? presumably the same cpu can execute thumb-mode instructions?
<thejpster[m]>
there are attributes you can apply to a function to select arm or thumb mode, but not to change the default. And the set of targets the attributes work for is only a subset of all arm targets, for no particular reason
<thejpster[m]>
> For the arm* targets, Thumb-mode code generation can be enabled by using -C target-feature=+thumb-mode. Using the unstable #![feature(arm_target_feature)], the attribute #[target_feature(enable = "thumb-mode")] can be applied to individual unsafe functions to cause those functions to be compiled to Thumb-mode code.
<thejpster[m]>
I was wrong, you can change the default. Except target-features aren't stable.
<adamgreig[m]>
still, I expect there might be some resistance to extra tier 2 targets just for that
<therealprof[m]>
i509vcb[m]: It's seemingly still used in A320s...
<adamgreig[m]>
I have to run, thanks everyone! let's hear back from Chris to see what we do about the armv8r target, and next week we can work through the member drive/cleanup
<JomerDev[m]>
<i509vcb[m]> "I'd certainly like to meet..." <- It's not quite in production, but I'm working on a project to extend older light controllers used by event technicians with newer features, where the processors are 68008 and 68020. The firmware is fully written in rust
<whitequark[cis]>
oh fascinating, this is actually useful to know
<jannic[m]>
<thejpster[m]> "like, do Ubuntu guarantee..." <- I'm not sure what Ubuntu guarantees, but the dependencies on each package include versions. So in theory the worst things that could happen would be that either the installation fails or installing qemu9 essentially upgrades the whole system to Ubuntu 24.10.
<jannic[m]>
In practice this is an untested combination, and it's easy to get some dependency wrong.
<jannic[m]>
In my experience such partial upgrades are quite reliable on Debian, but I have very little experience with Ubuntu.
<thejpster[m]>
maybe there's a statically linked alpine package?
<thejpster[m]>
> At present, Arch does not offer a full-system mode and statically linked variant (neither officially nor via AUR), as this is usually not needed.
<thejpster[m]>
boo
<JomerDev[m]>
<whitequark[cis]> "oh fascinating, this is actually..." <- Funnily enough, my current blocker is not having ever worked with an FPGA before and having to learn that bit by bit (and, yes I've looked at amaranth, but my python is also fairly rudimentary)
<whitequark[cis]>
feel free to ask for questions in the Amaranth channel ^^
<whitequark[cis]>
we unfortunately still don't have a first-party tutorial, but the guide/reference docs are written targeting the quality bar Rust has set, so they should be quite usable
<JomerDev[m]>
I've joined it, but I currently don't even really know where to start 😅
<whitequark[cis]>
if you have some idea of what it is you want to compute, then "how do I do [that]?" would be a good question to ask
<JomerDev[m]>
Fair enough. I do have examples for all parts that I'll need mostly written in verilog, though no real idea on how to combine them
<JomerDev[m]>
(In the end I'll need a qspi peripheral, a qspi controller and a way to emulate an eprom with up to 32bit address- and databus width)
<whitequark[cis]>
I will very much encourage you to use a simulator (any kind; amaranth.sim, verilator, cxxrtl, all good options) as this is probably the single biggest and most common mistake beginners make
<whitequark[cis]>
Glasgow has a QSPI controller you could borrow
<whitequark[cis]>
emulating an EPROM could be really challenging depending on your bus frequency
<whitequark[cis]>
well, and density
<JomerDev[m]>
Lets move this to the Amaranth channel, I don't want to spam the rust channel about this
<i509vcb[m]>
Maybe 10% brightness is hard to see outside lol
AlexandervanSaas has quit [Quit: Idle timeout reached: 172800s]
mux3dup[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
thejpster: for the qemu 9 topic: did you try to use the `container: ` feature of GH workflows? with that your GH actions will run in whatever container you specify there - so it doesn't matter if the underlying runner is e.g. Ubuntu 24.04; if you take an Ubuntu 24.10 image (i understand from the chat here that 24.10 includes qemu 9?) then you can use qemu 9 there (or pick any other docker image which comes with qemu 9).
<thejpster[m]>
<Ralph[m]> "thejpster: for the qemu 9 topic:..." <- Haven’t tried it. Sounds reasonable. Feel free to send a PR.
<Ralph[m]>
i'm not familiar with your repo and currently sadly quite underwater with some tasks (deadlines, deadlines everywhere... and some vacation coming up, shortening the time i have to get things done), so i'll have to pass on trying to make a PR right now. (i'll have more time in a few months. hopefully a lot more. then i'll be available for these kind of things again). just thought i'll throw it out there as a suggestion (i have used
<Ralph[m]>
the container: feature elsewhere (private repo; can't link it, sorry) already to get an image with the tools i needed and it worked like a charm)
be[m] has quit [Quit: Idle timeout reached: 172800s]