Dr_Who has quit [Read error: Connection reset by peer]
Dr_Who has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
diagprov has joined #rust-embedded
<re_irc>
<@emilgardis:matrix.org> can someone check this, https://github.com/m-labs/dslite2svd/issues/18, community is owner of the crates and I'm a bit confused about the situation there
<re_irc>
<@mameluc:matrix.org> : Exactly what I need, I tried implementing my own protocols that I could decode at run time. Then it hit me that I can just have the server decode logic and the firmware in the same workspace and just run postcard. By writing tests I can make sure I don't fuck up the decoding when I add stuff to the data structs
<re_irc>
<@mameluc:matrix.org> ofc having a .proto file would be more "proper" but this is good enough for now
<re_irc>
<@mameluc:matrix.org> I also had to solve the problem of how to pass data to the device but it worked out the same way but in reverse.
<re_irc>
iirc, so that you can build abstractions that safely steal the peripherals for you. for example, something like cortex_m_rt::entry could safely steal the peripherals for you (+) because it's the first thing that runs (you cannot call take before it) and it's a function guaranteed to only run once (steal is only called once). but for that to be "safe" ("safe" as in not break the singleton invariant without unsafe code; steal is unsafe) you must...
<re_irc>
... NOT be able to safely take another instance of the singleton after such a "safe" steal and that is achieved by having steal change the boolean flag that take uses.
<re_irc>
having the flag toggle in steal is not the only option though. you could have a separate, safe seal method that only modifies the boolean flag then steal does not have to touch the boolean flag. that change would be a breaking change (++) though, because safe abstractions like the one described before would need to change it's implementation from just calling steal to calling steal; seal
<re_irc>
(+) the macro would contain unsafe code. but you, the user of the macro, does not have to write unsafe code so the result passes #![deny(unsafe_code)]. 0.x versions of RTIC have this feature by the way. I don't know if the latest version still does
<re_irc>
(++) or you could take the position of "unsynchronized register access is never unsound" thus breaking the singleton invariant is not unsound either. that would let you remove the flag toggle in steal and call that a non-breaking-change on the grounds that steal should not even be unsafe in the first place. whether that would result in zero complaints from end users in practice: I do not know :shrug:```
<re_irc>
<@thejpster:matrix.org> More from Jorge:
<re_irc>
> iirc, so that you can build abstractions that safely steal the peripherals for you. for example, something like cortex_m_rt::entry could safely steal the peripherals for you (+) because it's the first thing that runs (you cannot call take before it) and it's a function guaranteed to only run once (steal is only called once). but for that to be "safe" ("safe" as in not break the singleton invariant without unsafe code; steal is unsafe) you must...
<re_irc>
... NOT be able to safely take another instance of the singleton after such a "safe" steal and that is achieved by having steal change the boolean flag that take uses.
<re_irc>
> having the flag toggle in steal is not the only option though. you could have a separate, safe seal method that only modifies the boolean flag then steal does not have to touch the boolean flag. that change would be a breaking change (++) though, because safe abstractions like the one described before would need to change it's implementation from just calling steal to calling steal; seal
<re_irc>
> (+) the macro would contain unsafe code. but you, the user of the macro, does not have to write unsafe code so the result passes #![deny(unsafe_code)]. 0.x versions of RTIC have this feature by the way. I don't know if the latest version still does
<re_irc>
> (++) or you could take the position of "unsynchronized register access is never unsound" thus breaking the singleton invariant is not unsound either. that would let you remove the flag toggle in steal and call that a non-breaking-change on the grounds that steal should not even be unsafe in the first place. whether that would result in zero complaints from end users in practice: I do not know :shrug:
<re_irc>
<@dirbaio:matrix.org> interesting
<re_irc>
<@dirbaio:matrix.org> > for example, something like cortex_m_rt::entry could safely steal the peripherals for you (+) because it's the first thing that runs (you cannot call take before it)
<re_irc>
imo the argument is a bit weak. That could use the "take()" instead. I guess the only advantage is slightly smaller code because it can skip the "panic if flag is already set" check
<re_irc>
<@thejpster:matrix.org> But if it called take they would not be available for anyone else to use later.
<re_irc>
<@thejpster:matrix.org> unless the entry macro passed them as the first argument to main(p: Peripherals)
<re_irc>
<@dirbaio:matrix.org> yeah, that's the point
<re_irc>
<@dirbaio:matrix.org> if you want the entry macro to take the peripherals and give them to main, you have 2 options
<re_irc>
<@dirbaio:matrix.org> - use take(), which has the overhead of checking the TAKEN flag that you know is not set
<re_irc>
- use the current version of steal(), it is sound since
<re_irc>
* the entry macro knows it's the first thing to run, so the TAKEN flag can't be set.
<re_irc>
* it still needs to set it, so that the user can't do "take()" later.
<re_irc>
<@dirbaio:matrix.org> if "steal()" didn't set the flag, the entry macro would be forced to use "take()"
<re_irc>
<@dirbaio:matrix.org> which has that tiny extra overhead
<re_irc>
<@dirbaio:matrix.org> - use take(), which has the overhead of checking the TAKEN flag that you know is not set
<re_irc>
- use the current version of steal() (that doesn't check, but still sets the TAKEN flag). It is sound since
<re_irc>
* the entry macro knows it's the first thing to run, so the TAKEN flag can't be set.
<re_irc>
* it still needs to set it, so that the user can't do "take()" later.
<re_irc>
<@dirbaio:matrix.org> so yea
<re_irc>
<@dirbaio:matrix.org> there _IS_ an argument in favor of "steal() should set the TAKEN flag"
<re_irc>
<@dirbaio:matrix.org> hah
<re_irc>
<@dirbaio:matrix.org> good to know the original reasoning from japaric himself
<re_irc>
<@dirbaio:matrix.org> that's only sound if "steal()" does set the TAKEN flag
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> perhaps it makes sense to have all 3?
<re_irc>
- "take": checks and sets the flag
<re_irc>
- "unsafe conjure": no check, no set
<re_irc>
- "unsafe take_unchecked": sets the flag
<re_irc>
<@dirbaio:matrix.org> the point would be moot if we stopped pretending singletons are necessary for soundness tho...
Dr_Who has quit [Quit: ZZZzzz…]
sauce has quit [Server closed connection]
sauce has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> We can't rename steal without just as much of a breaking change as having it not set the flag
<re_irc>
<@adamgreig:matrix.org> It's a shame the secret flag setting function of steal isn't documented but rtic relies on it for soundness, but there's a lot of rtic out there that does, so...
<re_irc>
<@thejpster:matrix.org> If you rename the method at least code stops compiling, instead of perhaps compiling in an unsound way.
<re_irc>
<@adamgreig:matrix.org> True, but it still stops compiling
<re_irc>
<@thejpster:matrix.org> If you make a breaking change should it be a case of "look at the picture full of stuff and work out what small thing changed" or "break it so hard no-one can miss it"
<re_irc>
<@dngrs:matrix.org> any value in marking it as deprecated and adding new method(s) with clearer semantics?
dne has quit [Server closed connection]
dne has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Also, just found the fst crate from burntsushi
<re_irc>
<@jamesmunns:beeper.com> oh, wrong room, but still a very cool crate :D