<re_irc>
<@davidarmstrongbarahonalewis:matrix.org> My goal here is to make it a bit more straightforward to get started with the discovery book as a newer nix user, but I'm not sure if it's appropriate to amend the book or what.
<re_irc>
<@adamgreig:matrix.org> ah, yea, I see the problem
<re_irc>
<@adamgreig:matrix.org> probably best bet is to wait for this new tool to be released, then package that for nix and at the same time the book is updated to talk about it
<re_irc>
<@adamgreig:matrix.org> at which point the book could mention that the tool is already available in nixpkgs
<re_irc>
<@davidarmstrongbarahonalewis:matrix.org> Cool. Happy to put this on ice until there's a new release. In the meantime, if you think it's helpful to amend the current Discovery book with any Nix-specific info, I'm happy to pull together a PR.
<re_irc>
<@davidarmstrongbarahonalewis:matrix.org> And thanks for taking the time to chat about this, I really appreciate it :)
<re_irc>
<@adamgreig:matrix.org> no problem! probably best hold off on PRs until this big merge is done (hopefully by end of this week) as it moves everything around, but after that if you want to add a sentence or two for nix users that sounds good. beware at the moment it says "*nix" everywhere to mean unix/mac/linux which is going to become a bit confusing, heh
<re_irc>
<@davidarmstrongbarahonalewis:matrix.org> lol - cool, I'll keep an eye on the PRs and revisit when they're merged ❤️
jackneilll has quit [Read error: Connection reset by peer]
jackneilll has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> Doesn't cargo's lock file essentially make Nix redundant? E.g. the lockfile locks down versions and cargo builds everything in isolation
<re_irc>
<@ryan-summers:matrix.org> At least for end applications. This obviously isn't true for lib crates
<re_irc>
<@jordens:matrix.org> From what I have seen nix doesn't trust cargo with reproducibly getting dependencies at all. It's a rather esoteric stance since cargo can still do whatever it wants under the hood and introduce non-determinism. I don't know of any nix maintainer actually checking anything when the hashes stop matching. They only ever blindly believe that it is benign and copy the new hash. Like constant TIFU.
jackneilll has quit [Ping timeout: 252 seconds]
jackneilll has joined #rust-embedded
jackneilll has quit [Remote host closed the connection]
jackneilll has joined #rust-embedded
<re_irc>
<@k900:0upti.me> The current best practice in Nix actually allows you to use the hashes pinned in Cargo.lock
<re_irc>
<@k900:0upti.me> Which is very nice
<re_irc>
<@k900:0upti.me> But very few packages actually switched to it
<re_irc>
<@jordens:matrix.org> That sounds much saner.
Foxyloxy has quit [Ping timeout: 250 seconds]
Foxyloxy has joined #rust-embedded
troth has quit [Ping timeout: 252 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 264 seconds]
troth has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> andres: Hmm, the Vec looks okay from a BSS perspective. Maybe `State`, `SubState`, or `ParserState` have non-zero const constructors?
<re_irc>
<@jamesmunns:beeper.com> Sadly if ANY part is non-zero, the data will end up in .data instead of .bss
troth has quit [Ping timeout: 268 seconds]
<re_irc>
<@luojia65:matrix.org> Hello! I have a RISC-V chip, its errata says that the manager core (also 64 bit RISC-V, but less complex) does not have an L2 cache access, it cannot use LR/SC atomic functions. That means my Rust firmware should be compiled under an RISC-V variant without atomic extensions. But rustc --print target-list shows there are only targets with atomic extensions on 64-bit RISC-V. What should I do to get around? :)
troth has joined #rust-embedded
<re_irc>
<@rahix:matrix.org> luojia65: you can create a custom target spec where atomics are disabled. no clue if that is enough in your situation, though
<re_irc>
<@jamesmunns:beeper.com> Also, I *feel* like I've had a device (or debugger?) get stuck with that output before, and unplugging and replugging the device + debugger might help
<re_irc>
<@jamesmunns:beeper.com> Not sure if it got locked into some kind of persistent hard-fault
<re_irc>
<@jkelleyrtp:matrix.org> My cargo.toml is as follows
<re_irc>
<@jamesmunns:beeper.com> Ah! The probe-run machinery (as far as I remember) is expecting you to have some kind of defmt-compatible method of logging
<re_irc>
<@jamesmunns:beeper.com> it doesn't support semihosting, as far as I know.
<re_irc>
<@jamesmunns:beeper.com> You might want to check out https://github.com/knurling-rs/app-template/, which includes the logging machinery that probe-run needs to get information from your devies.
<re_irc>
<@jamesmunns:beeper.com> If you *just* want to flash your device, and aren't interested in logs, etc, you might be interested in probe.rs' cargo-flash tool. probe-run is generally meant to be used as a "frontend" to embedded applications using defmt for logging and testing.
<re_irc>
<@jkelleyrtp:matrix.org> Ah! Thank you! I'll see if going through defmt fixes my issue
<re_irc>
<@jamesmunns:beeper.com> Yeah! Your output makes sense now: You're panicking in your code, and probe-run is trying to find the logging buffer in memory at the time of panic, and it's getting confused because it doesn't exist (because you aren't using it!)
<re_irc>
<@jamesmunns:beeper.com> so it is flashing and running your code, but confusing both you and itself :D
<re_irc>
<@jannic:matrix.org> To avoid that confusion, probe-run could print some hint if it never saw a valid rtt buffer.
<re_irc>
<@dirbaio:matrix.org> semihosting breaks with probe-run because it involves doing breakpoints (so the host sees it, handles whatever, then resumes the firmware), but probe-run treats a breakpoint as "firmware wants to exit"
<re_irc>
<@dirbaio:matrix.org> and unwinding is probably breaking due to the cursed inline-outline-asm
<re_irc>
<@grantm11235:matrix.org> Speaking of the struct-not-going-in-bss issue, would [once_cell](https://crates.io/crates/once_cell) help?
<re_irc>
<@jamesmunns:beeper.com> GrantM11235 you still need the initial value stored somewhere
<re_irc>
<@jamesmunns:beeper.com> when the whole initial value is zero: then it gets removed from the flash, and is just programatically initialized.
<re_irc>
<@dirbaio:matrix.org> if you got a huge struct which is almost all zero/uninit and a single nonzero byte, constructing it by code will be way smaller though
<re_irc>
<@jamesmunns:beeper.com> Is there a way to get the compiler to do that, without maybeuninit?
<re_irc>
<@dirbaio:matrix.org> with a plain static no :(
<re_irc>
<@firefrommoonlight:matrix.org> Shout-out to the above: The Knurling template is great
<re_irc>
<@jamesmunns:beeper.com> jannic:matrix.org: It did! It outputted:
<re_irc>
<@jamesmunns:beeper.com> > RTT logs not available; blocking until the device halts..
<re_irc>
<@jamesmunns:beeper.com> (could be a more clear message, they'd probably be up for a PR on that!)
<re_irc>
<@adamgreig:matrix.org> hi room, meeting time again! agenda is https://hackmd.io/q7WPWT8wSVW1f9ryGFt4CA, please add anything you'd like to discuss and we'll start in 5min
<re_irc>
<@adamgreig:matrix.org> ok, let's start!
<re_irc>
<@adamgreig:matrix.org> first quick announcement is that after the meeting last week thejpster is now on the tools team, welcome to another team!
<re_irc>
<@adamgreig:matrix.org> anyone else have any announcements?
<re_irc>
<@adamgreig:matrix.org> ok, onto `cross`, where we're still waiting for the RFC I hoped to write last week but didn't manage to, coming soon
<re_irc>
<@adamgreig:matrix.org> I don't think any other `cross` updates atm (is emilgardis around?)
<re_irc>
<@adamgreig:matrix.org> on the `discovery` book rewrite, we had some great feedback already in the PR https://github.com/rust-embedded/discovery/pull/414 but please do check over it, especially resource team members as we can hopefully get it merged soon
<re_irc>
<@adamgreig:matrix.org> if anyone has better ideas for the landing page though i'd be very interested as I feel it's quite plain at the moment
<re_irc>
<@therealprof:matrix.org> How to get XP? When to level up?
<re_irc>
<@hargonix:matrix.org> Regarding the preview page, did you update it already since the last suggestions i fixed? I cant for example see the RTOS link I put there
<re_irc>
<@adamgreig:matrix.org> no, I was about to do that but it seems most of my usb ports have stopped working so my ssh smartcard won't let me pull from github, sigh
<re_irc>
<@hargonix:matrix.org> Just so people dont have to go through the effort of pointing out my typos twice :p
<re_irc>
<@therealprof:matrix.org> Looks good to me, but it's a massive change...
<re_irc>
<@adamgreig:matrix.org> I'll update that very soon
<re_irc>
<@therealprof:matrix.org> (LGTM on a quick glance)
<re_irc>
<@jamesmunns:beeper.com> adamgreig: Did you do a kernel update? Arch does that to me sometimes :p
<re_irc>
<@adamgreig:matrix.org> no i just got home and resumed it :(
<re_irc>
<@adamgreig:matrix.org> one out of two keyboards is not working either but luckily that's above the critical threshold
<re_irc>
<@adamgreig:matrix.org> or below the threshold I guess, anyway
<re_irc>
<@adamgreig:matrix.org> ok, the preview should now be updated!
<re_irc>
<@adamgreig:matrix.org> anyway, please do check that out and leave feedback on the thread and we'll hopefully get it merged this week or so
<re_irc>
<@adamgreig:matrix.org> it replaces the previous `itm` crate which has not seen much maintenance (or bug fixes) with a new version that's more or less compatible (as I understand it), but solves a bunch of issues from the old version
<re_irc>
<@adamgreig:matrix.org> of note given we were just talking about the discovery book, the book still talks about an `itmdump` tool that used to be part of the `itm` crate and was removed a few versions back, so this is probably a good excuse to tidy up that part of the (old) disco book too
<re_irc>
<@eldruin:matrix.org> one coud replace all that stuff with rtt as well, which would promote the state of the art tooling as well
<re_irc>
<@eldruin:matrix.org> it just takes some work to go through the book
<re_irc>
<@therealprof:matrix.org> I'm not quite sure what the point of this PR is.
<re_irc>
<@adamgreig:matrix.org> the new book uses probe-rs and rtt already, which is nice
<re_irc>
<@therealprof:matrix.org> I'd rather get rid of the `itm` crate and replace it with a big sign: "If you're interested in itm, look here".
<re_irc>
<@firefrommoonlight:matrix.org> Defmt?
<re_irc>
<@firefrommoonlight:matrix.org> The knurling trinity is great
<re_irc>
<@firefrommoonlight:matrix.org> except when you want to print non primitives
<re_irc>
<@therealprof:matrix.org> Merging this PR would mean to take on a complete rewrite from a non-member under maintenance of the WG.
<re_irc>
<@adamgreig:matrix.org> I think tmplt was enthusiastic about joining the team to maintain that and the related parts of cortex-m (which they recently had a pr land in to implement a bunch of new debug functionality)
<re_irc>
<@adamgreig:matrix.org> the discussion here started at https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$5mmHzDECd57HlPN8uWBnBpuYhcWgSOoI6mmkVrlh_Fs?via=matrix.org&via=psion.agg.io&via=tchncs.de
<re_irc>
<@adamgreig:matrix.org> we're not exactly maintaining the current itm crate, so I don't think replacing it would be a huge change in status quo, except the new version solves current issues and brings fresh maintenance
<re_irc>
<@therealprof:matrix.org> The rewrite looks great, I'm just not convinved that having it under the hood of the WG makes a lot of sense.
<re_irc>
<@thejpster:matrix.org> As I understand it the remit of the WG is core functionality and traits that help others work in embedded Rust.
<re_irc>
<@adamgreig:matrix.org> I see the itm crate as a pretty core thing alongside the corresponding functions in `cortex-m`
<re_irc>
<@adamgreig:matrix.org> if some other org already had a fully featured alternative, e.g. probe-rs, that would be different
<re_irc>
<@adamgreig:matrix.org> but as long as it doesn't really exist elsewhere, I don't see an issue with us providing such a thing? same reason we had it to begin with
<re_irc>
<@thejpster:matrix.org> If it's part of coresight maybe it should be in cortex-m
<re_irc>
<@thejpster:matrix.org> Then it's for that team to merge or not?
<re_irc>
<@therealprof:matrix.org> Certainly a fair point, are there any plans in that direction?
<re_irc>
<@adamgreig:matrix.org> it's essentially part of coresight, but the itm crate entirely runs on the host computer, it's for interacting with the itm packets
<re_irc>
<@adamgreig:matrix.org> whereas the cortex-m crate is for the embedded-side stuff
<re_irc>
<@adamgreig:matrix.org> I agree it would be for cortex-m team, the current itm crate is maintained by cortex-m team iirc
<re_irc>
<@adamgreig:matrix.org> (yea, it is)
<re_irc>
<@thejpster:matrix.org> Ah, I see. We could move it to the community.
<re_irc>
<@adamgreig:matrix.org> it could be another crate in the cortex-m repo, for sure, though unlike cortex-m-rt and the semihosting stuff I'm not sure if there are technical reasons for it
<re_irc>
<@thejpster:matrix.org> Yeah I hadn't realised it was host software. My mistake.
<re_irc>
<@therealprof:matrix.org> Is there a roadmap for the new functionality?
<re_irc>
<@therealprof:matrix.org> There's also the issue, even if tmplt joins the team, if they are the sole developer of new functionality it will always require other people from the team to sign off on changes.
<re_irc>
<@adamgreig:matrix.org> yep, that's true
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> I'm not sure if there's a roadmap already, though I think there's also new functionality compared to our current version
<re_irc>
<@therealprof:matrix.org> I'd feel a lot better if more people expressed their interest in ITM.
<re_irc>
<@adamgreig:matrix.org> on balance my loose preference is to encourage people interested in helping with the various cortex-m things join the team, especially all this debug functionality that stands to be very useful for everyone but is not well developed yet
<re_irc>
<@therealprof:matrix.org> We had a spike of interest (or two) a while ago but it went dry quickly which is also the reason for the status quo.
<re_irc>
<@adamgreig:matrix.org> yea, it's a tricky one, I feel like with slicker tooling it would be such a nice thing - you can get such powerful debug information out of it, and a lot of serious use cases rely on it - but right now it's just fiddly enough to set up that print-over-rtt is more popular
<re_irc>
<@therealprof:matrix.org> I fully agreee.
<re_irc>
<@adamgreig:matrix.org> tmplt's rtic-scope project is driving their current interest in it I believe
<re_irc>
<@adamgreig:matrix.org> and as a topical example I think oxide computer's new humility debugger also relies on itm? https://github.com/oxidecomputer/humility
<re_irc>
<@adamgreig:matrix.org> so, I agree it's not hugely high-interest right now compared to RTT, but I think better tooling might help encourage it
<re_irc>
<@adamgreig:matrix.org> some of that can come from probe-rs outside of the wg, too, though
<re_irc>
<@adamgreig:matrix.org> it already has nascent itm/swo capability and will probably be essential to get more stuff going
<re_irc>
<@therealprof:matrix.org> If it's mostly about the itm crate on crates.io, I'd be willing to give that up.
<re_irc>
<@therealprof:matrix.org> Progress is a good thing and `itm` stalling out is certainly the opposite of that.
<re_irc>
<@adamgreig:matrix.org> yea, also an option
<re_irc>
<@adamgreig:matrix.org> let's maybe postpone further discussion until tmplt is around and we can see what their objectives are for having it in the wg?
<re_irc>
<@thejpster:matrix.org> RTT is also a SEGGER thing and it's good to have alternatives.
<re_irc>
<@thejpster:matrix.org> (not to SEGGER specifically, but to proprietary things in general)
<re_irc>
<@adamgreig:matrix.org> I think ITM is probably higher bandwidth too, and maybe lower cpu overhead
<re_irc>
<@adamgreig:matrix.org> but you need a probe that supports it and it needs to be wired up, so rtt's always going to be a bit easier
<re_irc>
<@adamgreig:matrix.org> so I feel like "develop itm-based tooling/support" is a fair objective for cortex-m team, since it's not very widespread at the moment
<re_irc>
<@adamgreig:matrix.org> in other words, it seems like a good area to be encouraging in
<re_irc>
<@adamgreig:matrix.org> but if the best way to be encouraging is to give up our itm repo so others can fight it out instead, we could do that :P
<re_irc>
<@therealprof:matrix.org> Well, one person obviously has interest in bringing that to the next level.
<re_irc>
<@adamgreig:matrix.org> and perhaps that effort would be helped by being in the wg?
<re_irc>
<@therealprof:matrix.org> I don't quite see the point of adding the drag of the whole group...
<re_irc>
<@thejpster:matrix.org> We could equivalently just write "deprecated" on our crate and give up or crates.io entry
<re_irc>
<@eldruin:matrix.org> we could also not lock the master branch and allow a more lax development cycle
<re_irc>
<@eldruin:matrix.org> still the team could help with more stuff
<re_irc>
<@therealprof:matrix.org> If they want to join the WG to furtther the cause that's of course more than welcome and I don't see the `itm` crate as a key for such a thing.
<re_irc>
<@eldruin:matrix.org> a bit like on the r-e-c
<re_irc>
<@thejpster:matrix.org> eldruin:matrix.org: I don't think that's something i could support
<re_irc>
<@therealprof:matrix.org> Yeah, pretty sure we can't do that.
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: Yes, that's my proposal from earlier. 😉
creich_ has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> therealprof:matrix.org: So you did
creich has quit [Ping timeout: 268 seconds]
<re_irc>
<@dirbaio:matrix.org> what's the requirement for something to be developed inside the WG?
<re_irc>
<@dirbaio:matrix.org> if "one motiivated person is willing to join the WG team and maintain the thing" is not enough, what is?
* cr1901
of course is just listening to the various perspectives- I have nothing to add here :)
<re_irc>
<@dirbaio:matrix.org> >2 people? Majority of the team?
<re_irc>
<@adamgreig:matrix.org> ultimately, by the book, it's just "the respective team votes to look after the repo"
<re_irc>
<@adamgreig:matrix.org> I feel like an enthusiastic volunteer who wants to help in an area we should be promoting should be enough
<re_irc>
<@adamgreig:matrix.org> but it's fair to ponder if it makes sense for a given crate to be inside the wg at all
<re_irc>
<@dirbaio:matrix.org> setting the bar too high will cause most of the stuff to be developed outside the WG
<re_irc>
<@adamgreig:matrix.org> I am about to write this rfc suggesting that we move cross out to its own org
<re_irc>
<@dirbaio:matrix.org> it seems like unnecessary gatekeeping to me
<re_irc>
<@adamgreig:matrix.org> I guess the philosophical question is whether ultimately the wg would maintain no crates at all :P or just some sense of pure central crates
<re_irc>
<@dirbaio:matrix.org> cross sure, because the embedded wg seems to be in the end about "real embedded, not linux embedded", so cross ended up being awkwardly on the edge of the scope
<re_irc>
<@dirbaio:matrix.org> but itm is definitely in scope
<re_irc>
<@adamgreig:matrix.org> yea, agreed
<re_irc>
<@adamgreig:matrix.org> charitably I think it's more about not wanting to take on additional responsibility rather than gatekeeping an exclusive club, but the effect in the end might be the same, and in any event we are already on the hook for maintaining the current `itm`
<re_irc>
<@thejpster:matrix.org> I don't see it as gatekeeping but an attempt to avoid ivory towers and boost equality.
<re_irc>
<@thejpster:matrix.org> You don't have to be a r-e crate to be the latest hip and cool thing.
<re_irc>
<@adamgreig:matrix.org> is that different from "you may not be a r-e crate even if you want to be involved"?
<re_irc>
<@therealprof:matrix.org> Yeah, with the same reasoning one could say `knurling` tooling and `probe-rs` stuff should better be inside the WG.
<cr1901>
Both perspectives would be valid from someone who isn't familiar w/ r-e I'm afraid
<re_irc>
<@adamgreig:matrix.org> it's a sort of sorry perspective if we conclude everything would be better outside the wg
<re_irc>
<@dirbaio:matrix.org> it's different, knurling people haven't proposed to develop their stuff inside the wg
<cr1901>
i.e. "it's gatekeeping" vs "it's to show you don't have to be under wg umbrella"
<re_irc>
<@adamgreig:matrix.org> I'd rather we were excited about new things happening inside the wg without being too worried it looks like we're saying only these golden crates are good or anything
<re_irc>
<@therealprof:matrix.org> adamgreig: Err, that's certainly not what I'm trying to convey here. It's more the question of "Are you sure you want this to be unter the maintenance of the WG? Or are you better off doing it outside?"
<re_irc>
<@adamgreig:matrix.org> the existence of knurling and probe-rs shows it's quite possible to work outside/alongside the wg, but why not let stuff happen inside if it wants, too?
<re_irc>
<@thejpster:matrix.org> I am excited about good things happening to ITM. I am very happy for the WG to talk about them and boost them.
<re_irc>
<@adamgreig:matrix.org> sorry, yea, I didn't mean to suggest you were saying that, just pondering if it looks the same from the outside
<re_irc>
<@adamgreig:matrix.org> thejpster: but not excited for them to happen inside the wg?
<re_irc>
<@thejpster:matrix.org> Placing a crate in r-e necessarily carries a maintenance burden we all must share
<re_irc>
<@thejpster:matrix.org> It's got to be pretty fundamental to making Embedded Rust a success to pay that price
<re_irc>
<@adamgreig:matrix.org> sure, that's definitely the threshold a team must decide a crate crosses
<re_irc>
<@therealprof:matrix.org> I'm fine with ITM being revived under our umbrella, I'm just not convinced it's the best move.
<re_irc>
<@adamgreig:matrix.org> but it feels like an `itm` crate could warrant that
<re_irc>
<@adamgreig:matrix.org> maybe it would not be the case if lots of ITM tooling already existed outside the wg
<re_irc>
<@adamgreig:matrix.org> I wouldn't say we should start a debugger, since probe-rs exists
<re_irc>
<@adamgreig:matrix.org> but as-is, the rest of the ecosystem hasn't worked on it so much, so maybe it's a good place to put some effort for now (or at least allow new people to join and put effort in)?
<re_irc>
<@thejpster:matrix.org> Joining, great. Many hands, etc. And I guess a PR on an existing repo is for the team to decide on.
<re_irc>
<@therealprof:matrix.org> Especially when someone is enthusiastic about turning something currently rather basic into something great, you don't want to slow them down by adding a ton of rules and constraints.
<re_irc>
<@adamgreig:matrix.org> yep! but since the team is me, you, therealprof, and thalesfragoso, it's us discussing it right now :P
<re_irc>
<@adamgreig:matrix.org> therealprof:matrix.org: I agree, but it's a balance between that and encouraging it by having it in the wg, I think
<re_irc>
<@adamgreig:matrix.org> I think "have PRs reviewed" is hopefully not a gigantic extra constraint but it would no doubt slow development somewhat
<re_irc>
<@therealprof:matrix.org> adamgreig: I don't see the relationship really. If they want to be in the WG, they can be independent of where `itm` is maintained.
<re_irc>
<@adamgreig:matrix.org> true, perhaps I'm unnecessarily conflating the two things
<re_irc>
<@thejpster:matrix.org> Ok, if I had to cast a vote, it would be to say "hey, why don't you finish that in a fork and when you're ready, we can talk about handing over the crate name because whilst it's super work it's not fundamental to the WG's mission and we don't want to hold you back"
<re_irc>
<@therealprof:matrix.org> adamgreig: I'm pretty sure at some point there're going to be design decisions to be made... and those discussions can drag on.
<re_irc>
<@adamgreig:matrix.org> 👍️ fair enough, thanks for the discussion!
<re_irc>
<@adamgreig:matrix.org> I think let's try and catch tmplt sometime and find out a bit more about the motivation for putting it into the wg and/or joining the team, but we're out of time for this meeting
<re_irc>
<@thalesfragoso:matrix.org> It seems like we ought to talk to the author, put the cards on the table and ask if they see a good amount of changes in the future
<re_irc>
<@thalesfragoso:matrix.org> and explain that with the itm in the org it might slow it down a bit
<re_irc>
<@thalesfragoso:matrix.org> if the their crate is pretty much done, then this might not be a concern
<re_irc>
<@thejpster:matrix.org> Point of reference - people maintain weird forks of the kernel and upstream stuff to Linus occasionally. I could see a blah/foobar-next where exciting stuff happened and a stable r-e/foobar that takes a PR a few times a year.
<re_irc>
<@adamgreig:matrix.org> yep, that could be a nice compromise between having a wg-supported crate and maintaining some development velocity in another repo
<re_irc>
<@adamgreig:matrix.org> though would make those occasional PRs a bit more of a challenge to review
<re_irc>
<@thejpster:matrix.org> Not saying that's the right approach here, just that is not in/out
<re_irc>
<@therealprof:matrix.org> At the moment there's this big refactoring PR which looks great and I'd be happy to merge it if we're certain that this is the direction we're continuing on in the future.
<re_irc>
<@therealprof:matrix.org> I think it would be bad to merge it and then hanging the whole project out to dry...
<re_irc>
<@thejpster:matrix.org> (I'm also going to bang my git-flow drum again but I'm going to do it quietly in the corner)
<re_irc>
<@adamgreig:matrix.org> I guess one way to look at it is that this is a big PR that writes basically the next point release of itm for us, fixing some bugs in the process, that we could just merge anyway
<re_irc>
<@adamgreig:matrix.org> so on those grounds alone it might make sense to merge it
<re_irc>
<@adamgreig:matrix.org> anyway, let's try and catch up with the author and continue next week?
<re_irc>
<@therealprof:matrix.org> Fair enough, but if we intend to release it we should also do our due diligence and make sure it works as advertised.
<re_irc>
<@thejpster:matrix.org> In other news (seeing as the meeting is over) I started at Ferrous Systems this week and picked up my MacBook Pro 14 yesterday. Holy smokes those things are amazing at compiling Rust.
<re_irc>
<@adamgreig:matrix.org> therealprof:matrix.org: yea, for sur
<re_irc>
<@adamgreig:matrix.org> ok, that's it for the meeting, thanks everyone!
<re_irc>
<@therealprof:matrix.org> adamgreig: I don't know about you but I'm currently in no position to do any ITM testing at the moment (both time and setup wise).
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: The only thing preventing me from upgrading (both hard and software) is that Apple is locking down their system more and more with every release. Have you felt any restrictions yet?
<re_irc>
<@thejpster:matrix.org> Nope. But I made my peace with proprietary software given ... *Points at GitHub, and Zoom and Teams*
<re_irc>
<@thejpster:matrix.org> I installed rust, brew and sublime. It just works. Well, the Wi-Fi went screwy for a bit...
<re_irc>
<@dirbaio:matrix.org> apple being able to tell you "no you can't run this binary on your $3.5k machine that you own" is a whole other level of proprietary though
<re_irc>
<@thejpster:matrix.org> They said that?
<re_irc>
<@thejpster:matrix.org> cargo install works fine
<re_irc>
<@thejpster:matrix.org> In fact my first cargo install wanted cc, so it said "hey, shall I install xcode tools for you?" and it downloaded clang for me.
<re_irc>
<@dirbaio:matrix.org> the notarization/signing stuff
<re_irc>
<@jamesmunns:beeper.com> I'm still holding out for Alpine Linux to be a daily driver, then I might upgrade my 3 year old Thinkpad X1 :p
<re_irc>
<@jamesmunns:beeper.com> Err, Asahi Linux
<re_irc>
<@dirbaio:matrix.org> I think the system linker signs the output with a local key or something, so it seems there are no restrictions for binaries that you compiled yourself
<re_irc>
<@dirbaio:matrix.org> but copy the binary to another machine and you'll get scary warnings
<re_irc>
<@dirbaio:matrix.org> unless you pay apple'sransom to "notarize" it
<re_irc>
<@thejpster:matrix.org> Right, but everything i want I either compile myself or it's the kind of tool that has a million downloads and will have been notarized
<re_irc>
<@therealprof:matrix.org> Things like valgrind tend to take longer and longer which each release until someone patches together a halfway working version...
<re_irc>
<@therealprof:matrix.org> Just when the Mojave version finally starts working with 10 patches, brew decides: Hey, we don't support that version anymore, go away...
<re_irc>
<@thejpster:matrix.org> How does homebrew work? Isn't it downloading binaries? Are they notarized?
<re_irc>
<@adamgreig:matrix.org> hopefully intel/amd will be woken up a bit by apple's stomping arm cpu and make fast cpus for the rest of us
<re_irc>
<@adamgreig:matrix.org> you can get wicked compile times if you give amd enough money today
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: It is downloading binaries (aka bottles) for supported versions.
<re_irc>
<@thejpster:matrix.org> I think we might have hit the end of the road transpiling ancient and huge instruction sets into RISC on the fly in hardware
<re_irc>
<@sourcebox:matrix.org> Is notarization required for all binaries or just installers?
<re_irc>
<@dirbaio:matrix.org> sourcebox:matrix.org: every single binary that you launch
<re_irc>
<@thejpster:matrix.org> Turns out you can get your compiler to emit the micro ops and transpile the old code on the fly in software
<re_irc>
<@sourcebox:matrix.org> I'm still on 10.13, so I can't check it.
<re_irc>
<@therealprof:matrix.org> They're not notarized, curious that they're running at all. Things like gdb had to be notarized for a number of versions already, or you can't run it at all.
<re_irc>
<@dirbaio:matrix.org> they even had macOS sending hashes of every binary you launch to apple's OCSP servers a while ago, they only fixed it when they got caught when their ocsp servers went down and no one could launch apps lmao
<re_irc>
<@thejpster:matrix.org> How can I check?
<re_irc>
<@sourcebox:matrix.org> If the binary is not notarized, is there a way to dismiss the warning?
<re_irc>
<@dirbaio:matrix.org> unrelated: has anyone done any RFID/NFC stuff in rust?
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: With `spctl`. But I'm not sure what exactly is enforced now.
<re_irc>
<@therealprof:matrix.org> /bin/bash: rejected (the code is valid but does not seem to be an app)
<re_irc>
<@dirbaio:matrix.org> I was wondering if there'd be interest to get some traits going, for example for iso14443-a/iso14443-b/iso-dep, so any protocol stack can use any rfid/nfc chip driver and stuff
<re_irc>
<@dirbaio:matrix.org> I guess it's a niche thing, probably there's not enough critical mass...??
<re_irc>
<@sourcebox:matrix.org> gdb has to be code-signed for quite a long time already. But I think this is because it can access sensible data.
<re_irc>
<@therealprof:matrix.org> dirbaio: Interest a lot, but the hardware is probably at the bottom of one of my shame boxes by now. 🤷🏻♂️
<re_irc>
<@dirbaio:matrix.org> shame boxes, in plural, lol :D
<re_irc>
<@therealprof:matrix.org> Two, yes.
<re_irc>
<@therealprof:matrix.org> The overflow was annoying.
<re_irc>
<@newam:matrix.org> Shame boxes... I still lie to myself and call them the "TODO boxes"
<re_irc>
<@dirbaio:matrix.org> I got a rust driver for the st25r39 stuff driver going :D
<re_irc>
<@dirbaio:matrix.org> iso14443-a only though
<re_irc>
<@therealprof:matrix.org> newam:matrix.org: Oh, I have a TODO box as well. 😉
<re_irc>
<@therealprof:matrix.org> I still have a few snowflake kits ready for building.
<re_irc>
<@therealprof:matrix.org> The firmware could use some update, too.
<re_irc>
<@dirbaio:matrix.org> and a wip mifare stack, but that's not going to get opensourced because NDAs :( :(
<re_irc>
<@therealprof:matrix.org> Even though the code is way outdated, the results are still amazing: https://www.youtube.com/watch?v=J5nDFbC8h-U . Pretty sure the code wouldn't compile anymore, though. 😬
radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@jamesmunns:beeper.com> dirbaio maybe reach out to the Solokeys folks re: NFC.
<re_irc>
<@jamesmunns:beeper.com> I think their new key has NFC and is written in Rust
<re_irc>
<@thejpster:matrix.org> So oxide computer published their RTOS today
<re_irc>
<@thejpster:matrix.org> I started at the bottom, looking at the arnn7-m and armv8-m specific stuff. There's a lot of cortex-m crate usage, which is weird.
<re_irc>
<@thejpster:matrix.org> I mean, it's not weird that they'd use it. That's what we wrote it for!
<re_irc>
<@thejpster:matrix.org> It's just weird seeing actual companies use stuff I've worked on. And as far as I can tell they didn't come in here and ask a bunch of questions (maybe they did? Hi! I failed your job interview!) - they just made cool stuff with our tools. Yay, composability!
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc>
<@thejpster:matrix.org> Lots of notes like this: `// Safety: this, too, is safe in practice but unsafe in API.`. I wonder if that can be improved or if it is necessarily like that.
<re_irc>
<@adamgreig:matrix.org> They have chatted here and made PRs and stuff, in probe-rs too
<re_irc>
<@adamgreig:matrix.org> Not extensively
<re_irc>
<@thejpster:matrix.org> I call that a win.
<re_irc>
<@thejpster:matrix.org> I mean, if everyone has to come here and go "wtf is this stuff?" I'd say we'd failed.
<re_irc>
<@thejpster:matrix.org> Unsolicited thoughts: that code has more static muts than I was expecting.
<re_irc>
<@thejpster:matrix.org> I've been trying myself in knots trying to use atomics instead because static mut == bad.
<re_irc>
<@whitequark:matrix.org> i wonder if there should be an equivalent of Cell that's Sync and doesn't give you &mut T
<re_irc>
<@whitequark:matrix.org> wait, no, that's unsound
<re_irc>
<@uep:matrix.org> thejpster:matrix.org: Yeah, I'm reading through the doc now and came here to post. Looks very cool.
<re_irc>
<@dirbaio:matrix.org> I wonder what they'll use for networking 👀
<re_irc>
<@sourcebox:matrix.org> Hmm... `static mut` is bad, so I use `Cell`. That is not Sync, so I need a Mutex. This requires a critical section. Any better solution?
<re_irc>
<@thejpster:matrix.org> https://github.com/oxidecomputer/hubris/blob/master/task/spd/src/main.rs - this program is for an MCU and it reads the Serial Presence Detect EEPROMs on all the DIMMs in the system. It then seems to set up an SPD emulator so that when the AMD main processor wants to read DIMM metadata, it comes from the cache stored in this program.
<re_irc>
<@sourcebox:matrix.org> AFAIK the CS means interrupt free. This is definitely not what I want.
<re_irc>
<@thejpster:matrix.org> Which I think is to allow the MCU to talk to the DIMMs and read their temperature without using the main CPU, but still letting the system actually boot and do DIMM training.
<re_irc>
<@thejpster:matrix.org> Which is /wild/
<re_irc>
<@thejpster:matrix.org> sourcebox: can you use atomic values?
<re_irc>
<@sourcebox:matrix.org> No.
<re_irc>
<@thejpster:matrix.org> You fundamentally can't have non-atomic shared mutable state and have a safe program
<re_irc>
<@sourcebox:matrix.org> But why do CS have to block interrupts?
<re_irc>
<@thejpster:matrix.org> To stop an ISR from writing to the variable at the same time.
<re_irc>
<@dirbaio:matrix.org> sourcebox:matrix.org: the compiler doesn't know that, it assumes everythign in `static`s can be accessed from separate threads
<re_irc>
<@uep:matrix.org> > The task’s memory protection configuration in the kernel is left unchanged, since there are no APIs changing a task’s memory protections.
<re_irc>
<@uep:matrix.org> I was wondering about this point about task reinit:
<re_irc>
<@uep:matrix.org> and how that could be true in the presence of what looks like shared memory borrows in the IPC mechanism. But it turns out they're not shared-memory between tasks, they're copy read/write via the kernel
<re_irc>
<@dirbaio:matrix.org> if you *do* know that, then just use `static mut` and `unsafe{}` to access it
<re_irc>
<@yatekii:matrix.org> adamgreig: well, mostly they did the hard work (the commits) and we stole it and made a PR :D
<re_irc>
<@grantm11235:matrix.org> grantm11235:matrix.org: Oh wait, you said *doesn't* give you a `&mut T`
<re_irc>
<@dirbaio:matrix.org> the `unsafe{}` is telling the compiler "I know what I'm doing, leave me alone"
<re_irc>
<@whitequark:matrix.org> grantm11235:matrix.org: yeah, I was thinking about having safe get/set methods, but that won't work
<re_irc>
<@sourcebox:matrix.org> I know that the compiler will protect me from myself, but at some point I need to be adult enough. Otherwise I can't do the job.
<re_irc>
<@dirbaio:matrix.org> then use unsafe, that's what it's for
<re_irc>
<@dirbaio:matrix.org> unsafe doesn't mean unsound
<re_irc>
<@dirbaio:matrix.org> if you ensure you only use the `static mut` from main, it's perfectly sound to use `unsafe` to access it
<re_irc>
<@dirbaio:matrix.org> (with some extra caveats, mostly that you mustn't get two &mut's from main at the same time)
<re_irc>
<@thejpster:matrix.org> dirbaio:matrix.org: Or use unsafecell
<re_irc>
<@thejpster:matrix.org> TIL the Oxide mainboards are called Gemini and Gimlet and have up to sixteen DIMMs. They're clearly not making tiny desktop PCs 🤔🤣
<re_irc>
<@thejpster:matrix.org> And we also suspect they'll run AMD chips, not Intel. I guess EPYC? Or some new unannounced silicon?
<re_irc>
<@thalesfragoso:matrix.org> sourcebox:matrix.org: RTIC mutexes are more granular, specially in thumbv7 and up
<re_irc>
<@thalesfragoso:matrix.org> If you want a baked safe solution
<re_irc>
<@dirbaio:matrix.org> RTIC still disables irqs
<re_irc>
<@thalesfragoso:matrix.org> Not all of them
<re_irc>
<@dirbaio:matrix.org> yeah yeah
<re_irc>
<@thalesfragoso:matrix.org> And you don't need to lock if you're the highway priority accessing that resource
<re_irc>
<@therealprof:matrix.org> sourcebox:matrix.org: Not necessarily, it just makes it harder to reason about WCET.
<re_irc>
<@thalesfragoso:matrix.org> And beware that using static muts can have some unexpected problems
<re_irc>
<@thalesfragoso:matrix.org> Like, just because you know some other thread isn't accessing at that specific time isn't enough
<re_irc>
<@thalesfragoso:matrix.org> You have to know that no other "thread" is accessing for the whole duration of that function, and probably other caveats
<re_irc>
<@sourcebox:matrix.org> In a typical use case, a bunch of ISRs do their job at very different locations.
<re_irc>
<@dirbaio:matrix.org> grantm11235:matrix.org: `Lazy` is
<re_irc>
<@dirbaio:matrix.org> cell: OnceCell<T>,
<re_irc>
<@therealprof:matrix.org> sourcebox:matrix.org: ... and they all share the exact same resources?
<re_irc>
<@sourcebox:matrix.org> No. They don't even know the different resources. An ISR handling UART is mostly not aware that some I2C busses exist and will never touch anything regarding it.
<re_irc>
<@therealprof:matrix.org> So why would you use a CS then if they don't share resources?
<re_irc>
<@sourcebox:matrix.org> Just because the Mutex requires it.
<re_irc>
<@sourcebox:matrix.org> At least the cortex-m ones.
<re_irc>
<@therealprof:matrix.org> You don't need a `Mutex` for a resource that is not shared.
<re_irc>
<@dirbaio:matrix.org> also `.put_with()` is guaranteed to construct the thing in place (instead of constructing in the stack and then moving)
<re_irc>
<@sourcebox:matrix.org> I don't want to use a mutex, but a cell is not sync, so it can't be static itself.
<re_irc>
<@therealprof:matrix.org> Yes, but you can use the `Mutex` to move your resources into the ISR that needs it and use it without any locking.
dcz_ has quit [Ping timeout: 252 seconds]
<re_irc>
<@sourcebox:matrix.org> I don't even have an ISR in my current case, I just don't want to block them globally.
<re_irc>
<@therealprof:matrix.org> I don't know what that is supposed to mean, I'm afraid. If you don't have ISRs, why care about keeping interrupts disabled?
<re_irc>
<@sourcebox:matrix.org> There are of course ISRs running, but they are not affecting anything at a place where I need the Mutex<Cell<...>>.
<re_irc>
<@dirbaio:matrix.org> caemor:matrix.org: it doesn't work because `<SPI as Write>::Error` could be anything, so rustc can't verify it won't cause conflicting impls
<re_irc>
<@therealprof:matrix.org> You don't need a Mutex for a resource that is not shared. You can move it out of the Mutex.
<re_irc>
<@dirbaio:matrix.org> there's no way around it afaik, you will ahve to manually `.map_err(|e| Error::Spi(e))?` instead of just doing `?`
<re_irc>
<@sourcebox:matrix.org> But I need a static Cell and this does not work without being wrapped.
<re_irc>
<@therealprof:matrix.org> This example is initialising a resource in `main`, moves it into the `Mutex` and the out of the `Mutex` in the IRQ handler upon first execution.
<re_irc>
<@sourcebox:matrix.org> Thanks, I see. But my use case seems to be very different.
<re_irc>
<@therealprof:matrix.org> I guess so, but it's hard to figure out what your use case is.
<re_irc>
<@sourcebox:matrix.org> Yes, and I think I'm not able to explain it sufficiently.
<re_irc>
<@therealprof:matrix.org> The cost of a critical section is often way overrated. If they're used sparingly and in the most efficient way they'll block ISRs for a couple dozen cycles each.
<re_irc>
<@firefrommoonlight:matrix.org> Static mut is appropriate for global buffers that need to be accessed across ISRs, cores, DMA etc
<re_irc>
<@firefrommoonlight:matrix.org> It's not a bad word
<re_irc>
<@therealprof:matrix.org> There're very few cases where that breaks a hard realtime system.
<re_irc>
<@therealprof:matrix.org> In order to have a guaranteed WCET quite a few assumptions have to hold...
<re_irc>
<@firefrommoonlight:matrix.org> For global primitives, atomics are a good first choice. For structs eg peripheral structs, config etc, shared resources with some type of lock (cortex-m Mutex, RTIC resource etc) are a good choice. For big / performance-sensitivive/cross-context arrays, `static mut` is the tool
<re_irc>
<@therealprof:matrix.org> But if that's what you're after your best option is to use RTIC which takes care of a lot of the hard stuff required to get there.
<re_irc>
<@grantm11235:matrix.org> firefrommoonlight:matrix.org: `static mut` can't be used on it's own to share data between ISRs, you need some kind of synchronization to ensure that you never have more than one `&mut T` alive at the same time
<re_irc>
<@sourcebox:matrix.org> Yes, that's also one of the reasons I want to avoid static mut.
<re_irc>
<@grantm11235:matrix.org> Are you trying to share something between ISRs or just move something into an ISR from main?
<re_irc>
<@sourcebox:matrix.org> ATM I'm not doing anything with ISRs at all, but the &mut problems also appear in other cases.
<re_irc>
<@grantm11235:matrix.org> If you aren't doing anything with ISRs, why do you need `Sync`?
<re_irc>
<@sourcebox:matrix.org> E.g. there is a I2C driver that is responsible for the bus. This has to be mutually shared with several structs that service the devices on the bus.
<re_irc>
<@thalesfragoso:matrix.org> 95% of the time the best solution is just to use RTIC or a framework/HAL that deals with interrupts for you (e.g. embassy)
<re_irc>
<@thalesfragoso:matrix.org> Or both at the same time
<re_irc>
<@thalesfragoso:matrix.org> sourcebox:matrix.org: That case you're probably better with a &'a RefCell
<re_irc>
<@sourcebox:matrix.org> Maybe this is a solution. Have to see.
<re_irc>
<@dirbaio:matrix.org> passing stuff around is usually nicer than using global variables
<re_irc>
<@dirbaio:matrix.org> if you pass stuff around rust *can* see you're not sending it to another thread, so it won't require Send/Sync