jackneillll has quit [Remote host closed the connection]
jackneillll has joined #rust-embedded
<re_irc>
<@chrysn:matrix.org> gdamjan: it's not the best answer you might be looking for, but IP over BLE (IPSP) is supported in RIOT, which is written in C but has Rust bindings to its network stack
<re_irc>
<@chrysn:matrix.org> dirbaio:matrix.org: Thanks dirbaio and James Munns , that's an aspect I haven't considered (and sorry for dropping off mid discussion, some events these days are hard to postpone ;-) )
<re_irc>
<@chrysn:matrix.org> I'll revisit my problem considering the possibility of the memory escaping, but I think that it works for this case as the memory mutated in the ISR is actually the pinned one.
<re_irc>
<@dirbaio:matrix.org> gdamjan: it should be easy to put it together using nrf-softdevice + smoltcp, haven't personally tried though
<re_irc>
<@chrysn:matrix.org> (and not some &mut that is part of the pinned structure).
<re_irc>
<@dirbaio:matrix.org> yeah if absolutely everything you access is inside the pinned thing you should be OK
<re_irc>
<@dirbaio:matrix.org> if the pinned thing borrows something else then no
<re_irc>
<@chrysn:matrix.org> but then is it sufficient to be behind a &mut Pin<&mut> in the main thread, or do I need to put the mutated stuff into an UnsafeCell or even something more extreme?
<re_irc>
<@dirbaio:matrix.org> how are you sending the pointer from main to irq?
<re_irc>
<@dirbaio:matrix.org> storing it in a static?
<re_irc>
<@chrysn:matrix.org> I'm calling an OS function, that inserts a part of the pinned struct into a global linked list
<re_irc>
<@dirbaio:matrix.org> btw `&mut Pin<&mut Thing>` will *not* work, you want the Pin guarantees to apply to the `Thing` and not to the `&mut Thing`
<re_irc>
<@dirbaio:matrix.org> I think no unsafecell should be fine
<re_irc>
<@dirbaio:matrix.org> you take a &mut to the contents, cast to raw pointer, send that to irq, let irq do its thing
<re_irc>
<@dirbaio:matrix.org> since the raw pointer comes from a valid &mut it has full rights to modify stuff
<re_irc>
<@dirbaio:matrix.org> of course you must ensure you don't access the thing from main until you're sure the irq is disabled
<re_irc>
<@chrysn:matrix.org> I'm not so much worried about the ISR's right to modify stuff, but about the assumptions the compiler may make in the main thread because I'm (inside critical sections) accessing the data in there (checking if some expiry thing has been set, for example)
<re_irc>
<@dirbaio:matrix.org> ah then that won't work
<re_irc>
<@chrysn:matrix.org> I don't access from main unless IRQs are off, but as far as the compiler is concerned, the main thread owns the struct, so it can't change, and even inside the unsafe cell the ownership can be used to create a &mut and a &mut unsafecell is safe to access
<re_irc>
<@chrysn:matrix.org> (so the compiler might maybe memoize the read in registers?)
<re_irc>
<@dirbaio:matrix.org> if you access the allocation directly, it invalidates all raw pointers
<re_irc>
<@dirbaio:matrix.org> kinda
<re_irc>
<@dirbaio:matrix.org> this stuff is mega tricky
<re_irc>
<@chrysn:matrix.org> but if i create a raw pointer for my access from the main thread (which is in the critical section)...?
<re_irc>
<@chrysn:matrix.org> (I'd probably throw in the UnsafeCell for good measure if doubt remains, but it feels a bit cargo culty)
<re_irc>
<@dirbaio:matrix.org> which is quite hard to interpret lol
<re_irc>
<@chrysn:matrix.org> aah, it's a short document, can't be that hard ;-)
* re_irc
@chrysn:matrix.org thinks of the two pages paper Gödel's incompleteness theorem was published on
<re_irc>
<@chrysn:matrix.org> thanks, I think that can get me to a point where I can at least make a better case for why what this winds up as is probably OK
<re_irc>
<@dirbaio:matrix.org> tldr is each memory location has a "stack" of borrows
<re_irc>
<@dirbaio:matrix.org> if you have a &mut then take a *mut from it, the stack is (bottom to top): `&mut *mut`
<re_irc>
<@dirbaio:matrix.org> at a given time, only the pointers in the stack are valid to access that memory location
<re_irc>
<@dirbaio:matrix.org> and when you use one pointer, all the other pointers on "top" of the stack get invalidated
<re_irc>
<@dirbaio:matrix.org> so for example if you then use the `&mut` from main to access it, the `*mut` gets invalidated because it was on top of it
<re_irc>
<@dirbaio:matrix.org> so the stack ends up looking like `&mut`
<re_irc>
<@dirbaio:matrix.org> and if later the ISR uses the `*mut` again, that's UB
<re_irc>
<@chrysn:matrix.org> ... but if I don't *use* the &mut (and reading it I'll know whether making a *mut out of it is considered usage) I'll be fine
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@chrysn:matrix.org> 🤯
<re_irc>
<@dirbaio:matrix.org> and then UnsafeCell has some "magic" that relaxes that
<re_irc>
<@dirbaio:matrix.org> so if oyu have multiple `&UnsafeCell<T>` pointing to the same place, it's still OK to use multiple of them to mutate the thing
<re_irc>
<@dirbaio:matrix.org> but still max only one `&mut` at onec
<re_irc>
<@dirbaio:matrix.org> so if you have one `&UnsafeCell<T>` in main, then send a ptr to that to irq (`*const UnsafeCell<T>`, not `*mut T`), then use it from both main and irq, you should be fine I *think*
<re_irc>
<@chrysn:matrix.org> i just hope this whole endeavor of wrapping RIOT's timers still turns out useful after considering the possibility of a leaked-and-never-reused pin content (i started out assuming the destructor was guaranteed to run, not that it was guaranteed to run unless the memory gets leaked for good)
<re_irc>
<@dirbaio:matrix.org> heh
<re_irc>
<@chrysn:matrix.org> dirbaio:matrix.org: Thing is, I still have ownership of the UnsafeCell<T> in main, but with stacked borrows what matters is that I only *use* it as an &UnsafeCell<T>
<re_irc>
<@dirbaio:matrix.org> uh
<re_irc>
<@dirbaio:matrix.org> I think
<re_irc>
<@dirbaio:matrix.org> the reasoning is
<re_irc>
<@dirbaio:matrix.org> the stack of borrows looks like this:
<re_irc>
<@dirbaio:matrix.org> where you have two copies of the `&`, in main and irq
<re_irc>
<@dirbaio:matrix.org> so when irq uses it, then
<re_irc>
<@dirbaio:matrix.org> same when main uses it, as long as both never use it at the same time, which the CS ensures
<re_irc>
<@dirbaio:matrix.org> otherwise you have UB like
<re_irc>
<@dirbaio:matrix.org> - main creates the &mut
<re_irc>
<@dirbaio:matrix.org> - irq creates its &mut, invalidating main's
<re_irc>
<@dirbaio:matrix.org> - main uses its &mut which is now invalid
<re_irc>
<@dirbaio:matrix.org> the magic of `UnsafeCell` is it allows you to convert `&` from `&mut `
starblue has quit [Ping timeout: 268 seconds]
neceve has joined #rust-embedded
starblue has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<@gdamjan:spodeli.org> hrm, I thought I could use 6LoWPAN with a normal Linux Ax200 bluetooth device
<re_irc>
<@k900:0upti.me> It depends
<re_irc>
<@k900:0upti.me> 6lowpan isn't really a singular protocol
<re_irc>
<@k900:0upti.me> You can run it over BT, but most things run it over 802.15
<re_irc>
<@gdamjan:spodeli.org> hmm, is it bt pan?
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> k900:0upti.me: Does anything actually support IPSP these days? When I last looked like... 5 years ago, I couldn't even figure out how to hackily make it work
<re_irc>
<@k900:0upti.me> It's not IPSP
<re_irc>
<@jamesmunns:beeper.com> Oh?
<re_irc>
<@k900:0upti.me> It's its own thing
<re_irc>
<@jamesmunns:beeper.com> Word. It's been a while
<re_irc>
<@k900:0upti.me> It runs over BLE
<re_irc>
<@k900:0upti.me> Hold on let me find the RFC
<re_irc>
<@k900:0upti.me> It's some unholy mess of C, Rust, Python and protobufs
<re_irc>
<@k900:0upti.me> I don't want to dig deeper to find out
<re_irc>
<@jamesmunns:beeper.com> To be clear: 6lowpan is not super easy to use it accessible, especially over ble
<re_irc>
<@jamesmunns:beeper.com> Like, I know a bunch of things run Thread these days, which is based on 6lowpan over 802.15.4, but I haven't found a ton of resources on that, and none in Rust
<re_irc>
<@jamesmunns:beeper.com> (or whatever Thread is called these days)
<re_irc>
<@gdamjan:spodeli.org> I don't think I have anything IEEE 802.15.4 around