jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
Noah[m] has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
bartmassey[m] has quit [Quit: Bridge terminating on SIGTERM]
burrbull[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
ScottGibb[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
adamhott[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
ted-996[m] has quit [Quit: Bridge terminating on SIGTERM]
FrreJacques[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
Lumpio[m] has quit [Quit: Bridge terminating on SIGTERM]
matoushybl[m] has quit [Quit: Bridge terminating on SIGTERM]
bitts[m] has quit [Quit: Bridge terminating on SIGTERM]
jackcloudman[m] has quit [Quit: Bridge terminating on SIGTERM]
Ralph[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
duderonomy has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
danielb[m] has joined #rust-embedded
<danielb[m]>
how is pointer provenance solved for memory-mapped registers? AFAIU conjuring pointers out of thin air is UB, but we can't expose provenance for those pointers because we don't have the pointers in the first place. Is everything just "UB and pray" here currently?
<danielb[m]>
* is UB unless some provenance has been exposed for them, but
diondokter[m] has joined #rust-embedded
<diondokter[m]>
<danielb[m]> "how is pointer provenance solved..." <- Right now volatile reads and writes work. And I think the project says that this will continue to work until they have an alternative ready.
<diondokter[m]>
The alternative will likely be new mmio_read and mmio_write functions. At least, that's what I heard last RustNL
<danielb[m]>
Hmm I was looking for an "it's not UB because register blocks are considered allocated objects by virtue of X" answer. I'm not sure how the quality of the operations change the pointer requirements currently listed in the rust documentation.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
I remember reading somewhere that they were discussing whether there's an exception for "memory not belonging to the abstract machine"
<dirbaio[m]>
like, if you construct a pointer from thin air and only ever use it to access memory not owned by the AM then it's fine
<danielb[m]>
ah cool
<danielb[m]>
* ah cool, thanks
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
johnpopeq[m] has left #rust-embedded [#rust-embedded]
thejpster[m] has joined #rust-embedded
<thejpster[m]>
I wonder if in general we need a concept of "assume that someone you can't observe has mutable access to this memory"
<JamesMunns[m]>
that's UnsafeCell
<thejpster[m]>
because a UART register block feels a lot like a block of memory you're sharing with another CPU (one that's running different firmware)
<JamesMunns[m]>
`UnsafeCell` means "don't make assumptions these contents haven't changed while you weren't looking (e.g. when you don't have a reference live), and that you promise that you will handle synchronization correctly.
<JamesMunns[m]>
but yeah, making it an unsafecell brings it "into" the AM, whereas with register ptrs + volatile (and proposed mmio methods), you're *supposed* to only use those for data outside of the AM
<thejpster[m]>
> This release is a semver-trick compatibility shim that allows packages using defmt = "0.3" to inter-operate with packages using defmt = "1.0".
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
<thejpster[m]> "I wonder if in general we need a..." <- Is this effectively C's 'volatile'?
<JamesMunns[m]>
It depends. volatile is used for mmio, but is misused for other synchronization very often
<whitequark[cis]1>
<thejpster[m]> "I wonder if in general we need a..." <- when working on amaranth-soc i made a point that multiprocessing and mmio feel very similar
<whitequark[cis]1>
for that reason i proposed using the ownership paradigm for managing mmio
<whitequark[cis]1>
like, have registers owned by peripheral xor core (or at least register bits, in a race free way)
<whitequark[cis]1>
there is also something to be said for multiple cores trying to talk to a single peripheral
<whitequark[cis]1>
the whole thing feels like an uphill battle tho
berkus[m] has joined #rust-embedded
<berkus[m]>
<danielb[m]> "how is pointer provenance solved..." <- Ub is conjuring start and end pointers and then doing arithmetic on them, because they are unrelated. Start+size should be fine.
<thejpster[m]>
Turning off cargo caching drops our build times for flip-link from ~5m30 to ~30 seconds. Except on Windows which only drops from 6m45 to 1m48, because using Microsoft's preferred systems programming language compiler on Microsoft's own Git hosting platform, running CI pipelines on Microsoft's own operating system, on top of Microsoft's own cloud infra, takes 3x as long as using Linux.
<dirbaio[m]>
caching on github actions is turbo-garbage, yes
<thejpster[m]>
`::<garbage>`
<dirbaio[m]>
it often takes more time to download+decompress+compress+upload than what it saves
<thejpster[m]>
The Ferrocene engineers have spent many hours being very angry at Windows ports of tar and zip, yes.
<thejpster[m]>
I think at one point we decided to shell out to Python and use the tarfile module because it was considerably faster.
<thejpster[m]>
Like how it's faster to shell out to PHP to run a regular expression than to use C++'s std::regex.
<thejpster[m]>
computers may, on reflection, have been a mistake
<danielb[m]>
<thejpster[m]> "computers may, on reflection..." <- sand is taking its revenge on us
<JamesMunns[m]>
for the sake of sharing (not MMIO, but similar "spooky memory tricks"), I recently did a "write a message to uninit ram to share between bootloader and app", this is my currently recommended practices, but I'd probably still not call it 100% sound, because I do potentially read uninit ram (and I should probably do these actions in a critical section):
<ivmarkov[m]>
<mheld[m]> " /Users/gregor/.espressif/tools..." <- I just answered you in the other room. Cross posting is not a good idea, esp. going from a specialized room on the subject to a more generic one :)
<mheld[m]>
<ivmarkov[m]> "I just answered you in the other..." <- understood! ty ivmarkov !
cmooon has joined #rust-embedded
ouilemur has quit [Quit: WeeChat 4.5.1]
AndoThorNando[m] has joined #rust-embedded
<AndoThorNando[m]>
I’ve been writing a blog post implementing a device driver using [@diondokter:matrix.org](https://matrix.to/#/@diondokter:matrix.org)’s device-driver crate. I’ve not yet posted it but if anyone would like to review that draft I’d appreciate any feedback you’d might have:
<diondokter[m]>
<AndoThorNando[m]> "I’ve been writing a blog post..." <- > <@voidedgin:matrix.org> I’ve been writing a blog post implementing a device driver using [@diondokter:matrix.org](https://matrix.to/#/@diondokter... (full message at