-
Notifications
You must be signed in to change notification settings - Fork 48
IDL gen improvements 2 - Convert all system clusters to use the import!
macro
#237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
import!
macroimport!
macro
b503b03
to
09e0983
Compare
09e0983
to
c660548
Compare
Downstream changes after this PR: |
c660548
to
3d659ef
Compare
38d56ce
to
a436562
Compare
a436562
to
faf9b0a
Compare
ff91515
to
13e8426
Compare
@bjoernQ Let me expand on something which might not be quite clear when you read the concrete changeset. Since ~ 1y, There are multiple attempts at solving the above issue, like Google's
But why the need for in-place initialization in What Similarly, An alternative to the whole |
Update: blog ^^^ The "placement by return" section is of a particular interest, as it touches on the existing RFC in rust, as well as on the |
Thanks for the additional background! I was aware of the in-place-construction problem and your efforts to reduce stack usage but the details help a lot 👍 (also thanks for the link to that blog post) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the change from Cluster to Handler and I generally like using abbreviations - not sure I exactly like CommPolicy
- while it's probably clear in the context of Matter, Comm
reads to me like communication but that's pretty much just a matter of taste.
Otherwise, all the changes look good to me. Ran a few tests on a Linux machine.
I'm also a bit torn on this, but the same applies to Since I abbreviated |
Also... unfortunately we cannot abbreviate whatever names come from the IDL, but alas, that is life... |
NOTE: PR #233 needs to be merged first!As mentioned in #233, this is the next PR in the sequence which converts ALL
rs-matter
system clusters and their handlers to use theimport!
macro.As part of this conversion, I've renamed the module name of each cluster + handler to a shorter variant, because the content of each cluster module file is anyway almost completely redefined now that it uses most of the
import!
auto-generated types. This work had already started in the previous PR with e.g.cluster_basic_information
renamed to justbasic_info
. E.g.:admin_commissioning
=>adm_comm
nw_commissioning
=>net_comm
general_diagnostics
=>gen_diag
thread_nw_diagnostics
=>thread_diag
wifi_nw_diagnostics
=>wifi_diag
Note that I've resisted the inner urge to also rename/shorten upper-level package names. This could wait for a subsequent PR.
Also, what used to be named
*Cluster
is now named*Handler
. We should really keep theCluster
terminology for the "meta-data" aspect of a cluster, and useHandler
for the actual code that reads/writes attributes and executes commands. This is also matching the genericHandler
andAsyncHandler
traits names whichrs-matter
uses since a long time.===
This PR also introduces the
rs_matter::data_model::networks
utilities, which are a simplified and more streamlined variant of what used to be inrs-matter-stack
. I think these utilities do deserve to live inrs-matter
proper instead, as they are not really opinionated (rs-matter-stack
is an opinionated instantiation ofrs-matter
that decides for you how the stack should be organized and polled), and moreover, user might use none, a few or all of these utilities. But the reality is, if you plan to users-matter
over a wireless network (Thread or Wifi) and you don't take advantage of those utilities, you are in for a lot of coding, hence another reason they should be inrs-matter
.These utilities include:
Networks
as well as a sample implementation (WirelessNetworks
) that model the storage for wireless networksEthernet
network storage (as per spec)WirelessMgr
), which - upon commissioning a wireless operational network - can be used (and is used downstream) to monitor for wireless network disconnection and tries to re-connect the existing (and the other) networks registered in the storageNetCtl
,WifiDiag
,ThreadDiag
andWirelessDiag
traits that need to be implemented downstream and which model the (wireless) network adapter state and its controller, capable of scanning for wireless networks as well as connecting to a wireless networknetworks
module===
PC:
rs-matter
examples, andrs-matter-stack
examples.Baremetal:
These changes are in the meantime tested with
rs-matter-stack
andrs-matter-embassy
downstream. The relevant PRs are:Due to an unfortunate set of events (embassy-sync 0.7, bt-hci 0.3 and others), I have only tested these changes with RP Pico W and the NRF2040, and can't (yet) test with the ESP (whose BT stack is still at embassy-sync 0.6 and bt-hci 0.2).
But I don't expect any surprises there. Testing might be possible if we switch to latest
main
ofesp-hal
inrs-matter-embassy
though, as I did for the RP and NRF? This would require patchingopenthread
as well though, as it is still onesp-hal
0.23