explore has quit [Quit: Connection closed for inactivity]
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
<re_irc>
<sib1234> Hi all. I'm doing some analysing of embedded rust. Right now I'm have my eye on the size for the builded binary. But I ran into a problem I'm compiling with the --release to get rid of the debugging sectors. But by analysing the elf I found out the debugging sectors are still there. Does someone have any idea?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<alvela> Hey folks, currently working on a project using the w5500 crate and I'm running into an issue where I'm unable to use the "connect()" method on an initialized socket due to its implementation being private. This is my first time using anything related to embedded-nal, so it's likely I'm missing something. I'd appreciate any help, though!
<re_irc>
error[E0624]: associated function `connect` is private
<re_irc>
<alvela> (Apologies for taking up that much window space w/ example. Not sure if it's better to link files in the future?)
<re_irc>
<sib1234> Hi all. I'm doing some analysing of embedded rust. Right now I'm have my eye on the size for the builded binary. But I ran into a problem I'm compiling with the --release to get rid of the debugging sections. But by analysing the elf I found out the debugging sections are still there. Does someone have any idea?
<re_irc>
< (@jannic:matrix.org)> Regarding usage of critical-section 0.2: I currently get an indirect dependency on that version via "heapless" 0.7.16 → "atomic-polyfill" 0.1.10 → "critical-section" 0.2.7.
<re_irc>
Am I missing something or is a new release of "heapless" needed to avoid that?
<re_irc>
< (@jannic:matrix.org)> (And I wonder how many such indirect dependencies we missed when we assumed that only 4 crates depend on the old version)
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
< (@dirbaio:matrix.org)> so what's the right query then
<re_irc>
< (@dirbaio:matrix.org)> * then?
<re_irc>
< (@dirbaio:matrix.org)> "gimme all crates whose latest vesion depends maybe indirectly on c-s 0.2"
<re_irc>
< (@dirbaio:matrix.org)> how do you do that
<re_irc>
< (@jannic:matrix.org)> Walk the tree of crates which depend on c-s (all versions), and then for each of those crates check if the latest version (indirectly) depends on c-s 0.2?
<re_irc>
< (@dirbaio:matrix.org)> download the crates.io sql then write a monster recursive query? :D
<re_irc>
< (@jannic:matrix.org)> There are many crates still depending on defmt-rtt 0.3, but that's usually an optional dependency, fortunately. Still an easy way to accidentally include c-s 0.2, and if c-s 0.2 is yanked, builds enabling that feature will break.
<re_irc>
< (@dirbaio:matrix.org)> for defmt-rtt many are dev-deps
<re_irc>
<Paul Paterson> I am working on an RTIC project with rp2040, my main.rs file is growing very large and I am having trouble figuring out how to encapsulate parts of the project.
<re_irc>
Are there any non-trivial OSS examples that folks are aware of that can demonstrate this?
<re_irc>
It seems like my own only option is to create a function that accepts an "app::my_task::SharedResources" argument, since the individual shared resource types are private. Does that sound about right?
<re_irc>
<Paul Paterson> pico-probe doesn't use any shared resources, which does complicate some things, but there's a lot there in the repo, great example, and cool project!
<re_irc>
<Paul Paterson> * repo. Great
<re_irc>
< (@9names:matrix.org)> agreed, makes RTIC look easy
<re_irc>
< (@jannic:matrix.org)> : Without having done a systematic survey, after just clicking through the dependencies for a while, it looks like heapless 0.7 is the biggest issue. Even once there is a version 0.8 released, it will take a while to propagate that to all the crates depending on heapless. There are a lot of them!
<re_irc>
< (@dirbaio:matrix.org)> and all through atomic-polyfill
<re_irc>
< (@dirbaio:matrix.org)> where I bet the vast majority of these aren't even hitting the "polyfill" part of atomic-polyfill
<re_irc>
< (@dirbaio:matrix.org)> uuurgh
<re_irc>
< (@grantm11235:matrix.org)> Most people using heapless probably aren't even using any of the atomics at all, since it isn't used in heapless::Vec
<re_irc>
< (@dirbaio:matrix.org)> yea that too :C
<re_irc>
< (@dirbaio:matrix.org)> I wonder if we can release an "atomic-polyfill 0.1.x" update using "critical-section" 1.0
<re_irc>
< (@dirbaio:matrix.org)> it's a breaking change, it'll cause a build failure if you don't have any "cs 1.0" impl
<re_irc>
< (@dirbaio:matrix.org)> but it'll break only the targets that do need polyfilling
<re_irc>
< (@dirbaio:matrix.org)> vs just yanking cs0.2 which will break everything
<re_irc>
< (@jannic:matrix.org)> The same could be done directly to critical-section: When yanking versions <=0.2.7, publish a version 0.2.8 which just doesn't provide the cs impls.
<re_irc>
That way, crates indirectly depending on c-s 0.2 without actually using it will still work.
<re_irc>
< (@jannic:matrix.org)> Of course, that would be a breaking change in 0.2.7 → 0.2.8, but not worse than just yanking 0.2 completely.
<re_irc>
< (@dirbaio:matrix.org)> lol
<re_irc>
< (@jannic:matrix.org)> In the end we could have done that from the start, instead of bumping c-s to 1.0 :-)
<re_irc>
< (@dirbaio:matrix.org)> 1.0 also introduced configuring the "restore state" type, which needed a breaking change too
<re_irc>
< (@dirbaio:matrix.org)> dunn
<re_irc>
< (@dirbaio:matrix.org)> * dunno
<re_irc>
< (@dirbaio:matrix.org)> IMO if most of the "leakage" of cs0.2 into the ecosystem is through atomic-polyfill 0.1, that's a good place to "patch" it
<re_irc>
< (@dirbaio:matrix.org)> in a way that's not complete sabotage (cause unconditional build failure)
<re_irc>
< (@grantm11235:matrix.org)> Could a new cs 0.2.x provide a default impl based on an 1.0 impl?
<re_irc>
< (@dirbaio:matrix.org)> and then just plain old yank cs0.2
<re_irc>
< (@dirbaio:matrix.org)> : we tried, but it's not easy due to the RestoreState being a different type
<re_irc>
< (@dirbaio:matrix.org)> honestly I think yanking is better than releasing some semver-breaking change
<re_irc>
< (@dirbaio:matrix.org)> yanking gives a clear error message "version X is yanked, pls update"
<re_irc>
< (@dirbaio:matrix.org)> and cs0.2 is _unsound_ after all
<re_irc>
< (@dirbaio:matrix.org)> that's what yanking is for
<re_irc>
< (@jannic:matrix.org)> That's fine for people who depend on c-s directly. But if you depend on some third-party library which then (probably indirectly) depends on c-s 0.2, you have to wait for an update of that other library.
<re_irc>
< (@dirbaio:matrix.org)> yea
<re_irc>
< (@dirbaio:matrix.org)> so let's PR updates to libs
<re_irc>
< (@dirbaio:matrix.org)> then yank
<re_irc>
< (@jannic:matrix.org)> And: Yes, yanking is meant to be used if some crate is unsound or otherwise dangerous. But it's usually expected to replace it with a semver-compatible fixed version. (At least that's my understanding.)
<re_irc>
< (@dirbaio:matrix.org)> but we can't do that here... it's unsound due to the default impls, and removing them is a breaking change :S
<re_irc>
< (@mabez:matrix.org)> : Is it actually possible to fix 0.2 in a semver compatible way though? If not, then its better just point people to 1.0 right?
<re_irc>
< (@dirbaio:matrix.org)> it's not the default impl being wrong, it's the fact that the default impl _exists_ that causes the unsoundness
<re_irc>
< (@dirbaio:matrix.org)> so you can't simply "fix" it
<re_irc>
< (@jannic:matrix.org)> Sure, this is was makes this situation difficult.
<re_irc>
< (@grantm11235:matrix.org)> Isn't it also a breaking change for a library to change from cs 0.2 to cs 1.0? And all the libraries that depend on that library need to make a breaking change to update, etc
<re_irc>
< (@jannic:matrix.org)> Yes, and just yanking 0.2 would also be a breaking change. We probably can't avoid that. It's still open which kind of breaking change would be the preferred one.
<re_irc>
<|cos|> Would https://rustsec.org/advisories/ be a tool communicate cs0.2 being unsound, perhaps? It's not a vulnerability nor a matter of an abondoned crate, but maybe it fits there anyways?
<re_irc>
< (@dirbaio:matrix.org)> i'm not a fan of the "unsoundness = vulnerability" mentality rustsec has
<re_irc>
< (@dirbaio:matrix.org)> but yea, it's an option I guess
<re_irc>
< (@dirbaio:matrix.org)> does it matter if we yank it though?
<re_irc>
<|cos|> I'm thinking, as a painter of the bikeshed, that any actions one might take prior to yanking is helpful.
<re_irc>
< (@jannic:matrix.org)> A hypothetical version 0.2.8 could provide the "with" method in terms of version 1.x:
<re_irc>
"acquire", "release" and "trait Impl" would vanish, together with the default impl, which is the breaking part of this change. But library crates only using "with" to run some code inside a critical section would keep working, as long as the binary also provides an c-s implementation.
<re_irc>
}
<re_irc>
< (@dirbaio:matrix.org)> oooh hmhmhmhm
<re_irc>
< (@dirbaio:matrix.org)> maybe we can do acquire/release too if restorestate <= u8 ?
<re_irc>
< (@jannic:matrix.org)> Maybe we could, but how shall we know what's the restorestate is?
<re_irc>
< (@jannic:matrix.org)> * what the restorestate type
<re_irc>
< (@dirbaio:matrix.org)> some typelevel hax...?
<re_irc>
< (@dirbaio:matrix.org)> impl some trait for "()", "bool", "u8"
<re_irc>
< (@dirbaio:matrix.org)> let it fail with "u32 doesn't impl the trait" for bigger ones
<re_irc>
< (@jannic:matrix.org)> Yes, that might work.
<re_irc>
< (@dirbaio:matrix.org)> what about setting a custom impl? we just break that, or somehow translate it to cs1.0?
<re_irc>
< (@dirbaio:matrix.org)> the trait is compatible if "RawRestoreState = u8"
<re_irc>
< (@dirbaio:matrix.org)> the macro is too
<re_irc>
< (@dirbaio:matrix.org)> ah, the public RestoreState doesn't allow accessing the inner "()", "bool" or "u8"
<re_irc>
< (@jannic:matrix.org)> But calls the "extern "Rust"" functions directly. That allows access to the "RawRestoreState".
<re_irc>
< (@dirbaio:matrix.org)> oh lol I didn't think about calling these directly
<re_irc>
< (@dirbaio:matrix.org)> nice
<re_irc>
< (@dirbaio:matrix.org)> yeah yours is better
<re_irc>
< (@dirbaio:matrix.org)> "with" should use the 1.0 "with" directly though, that way it still works with the bigger restore states
<re_irc>
< (@jannic:matrix.org)> : Yes, and that are also the cases where we (probably?) can't avoid breaking. We can't just provide an impl. And we can't fix conflicting impls.
<re_irc>
< (@jannic:matrix.org)> "trait Impl" can probably be removed? The only use case would be implementing a custom impl, which won't work.
<re_irc>
< (@dirbaio:matrix.org)> if you make "custom-impl" enable "critical-section-1/restore-state-u8", you can directly reexport the macro+trait
<re_irc>
< (@dirbaio:matrix.org)> which I think _should_ work
<re_irc>
< (@dirbaio:matrix.org)> the macro, trait are compatible (other the macro rename)