-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Changing AcceptedCommands Interface #37646
base: master
Are you sure you want to change the base?
Changing AcceptedCommands Interface #37646
Conversation
8f1e074
to
601f2cc
Compare
601f2cc
to
3a551c1
Compare
PR #37646: Size comparison from 43a8a9b to 3a551c1 Increases above 0.2%:
Full report (73 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
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.
Requesting changes: the moving of the files and adding of admin_storage
is suspicious. please at a minimum:
- do not add
admin_storage.json
to the PR - do not move files from
data-model-provider
intodata-model
. They are not the same thing. If you have dependency/compile issues you probably need to fix dependencies in chip_data_model.gni or similar.
src/app/clusters/device-energy-management-server/device-energy-management-server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
Co-authored-by: Andrei Litvin <andy314@gmail.com>
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
PR #37646: Size comparison from 54afa4a to 7f56e9f Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nxp, psoc6, qpg, stm32, telink, tizen)
|
src/app/clusters/microwave-oven-control-server/microwave-oven-control-server.cpp
Show resolved
Hide resolved
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
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.
Approviding assuming remaining comments addressed:
-
please double-check all command flags with the spec. Maybe add a summary in the PR for all replaced so we make sure they are ok. These are tedious to check :(
-
we may choose to appendelements everywhere even for 1-element lists as that is less clunky than ensuresize+append. We can add a tech debt issue to have an append that auto-reallocates (not having that was on purpose since I thought it would encourage people to static allocate more ... but unsure if that is effective)
PR #37646: Size comparison from 54afa4a to afc80b1 Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nxp, psoc6, qpg, stm32, telink, tizen)
|
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
PR #37646: Size comparison from 54afa4a to 8c10c16 Increases above 0.2%:
Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nxp, psoc6, qpg, stm32, telink, tizen)
|
docs/upgrading.md
Outdated
Be sure to use `EnsureAppendCapacity` before single element Append | ||
`ListBuilder::Append` as it will not grow the buffer if not available already |
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.
This sentence has grammar issues.
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.
Please check new phrasing
using QF = DataModel::CommandQualityFlags; | ||
using Priv = chip::Access::Privilege; | ||
|
||
ReturnErrorOnFailure(builder.AppendElements({ |
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.
Does this not need EnsureAppendCapacity before AppendElements?
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.
Not really, AppendElements already ensures capacity before, only when using Append is necessary
src/app/clusters/device-energy-management-server/device-energy-management-server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/resource-monitoring-server/resource-monitoring-server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/software-diagnostics-server/software-diagnostics-server.cpp
Outdated
Show resolved
Hide resolved
src/app/clusters/software-diagnostics-server/software-diagnostics-server.cpp
Outdated
Show resolved
Hide resolved
/// | ||
/// Automatically attempts to allocate sufficient space to fulfill the element | ||
/// requirements. | ||
CHIP_ERROR AppendElements(std::initializer_list<T> span) { return AppendElementArrayRaw(span.begin(), span.size()); } |
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.
OK, so are the capacity bits before these calls just optimizations then? That should be documented.
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.
yes, and no, Single element Append doesn't allocate and just fails, MultiAppend, aka AppendElements, does allocate as needed.
I don't like the inconsistency either, I feel is error prone, chatted with @andy31415, and will create a ticket to tech debt to figure out a better way and fix otherwise
I suggested renaming Append
to TryAppend
for the non-allocating function and optionally adding an Append
which does the Ensure, also optionally a TryAppendElements
for symmetry, and further optimization.
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.
As a background, we tried making the Auto-append
clunky to encourage people to use "static arrays" instead (larger memory allocations if needed and ability to re-use pointers). In practice when things are conditional, it seems we still kind of default to "append". .... I would probably err on the side of just renaming append to TryAppend and documenting that you may not want to actually use this and prefer to call AppendElements. Or we can also completely drop Append
from the public interface.
What I want to avoid is everyone doing Append, Append, Append
because it is convenient to write and cause many re-allocations as a result.
src/app/clusters/network-commissioning/network-commissioning.cpp
Outdated
Show resolved
Hide resolved
Co-authored-by: Andrei Litvin <andy314@gmail.com>
Fixes #37139
Cluster Changes:
Network Comissioning
Spec/NetworkCommissioning#Commands

NetworkCommissioning::EnumerateAcceptedCommands
Device Energy Management
Spec/DeviceEnergyManagement#Commands

DeviceEnergyManagement::EnumerateAcceptedCommands
Energy Evse
Spec/EnergyEvse#Commands

EnergyEvse::EnumerateAcceptedCommands
Resource Monitoring
Spec/ResourceMonitoring#Commands

ResourceMonitoring::EnumerateAcceptedCommands
Spec/SoftwareDiagnostics#Commands

SoftwareDiagnostics::EnumerateAcceptedCommands
Testing
Manually tested