[Matter.framework] Move various #define to src/platform/Darwin/CHIPPl… #36178
+38
−139
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review changes with SemanticDiff. |
|
PR #36178: Size comparison from 605e3f5 to d5ca4ab Full report (24 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, nrfconnect, qpg, stm32, telink, tizen)
|
vivien-apple
force-pushed
the
MatterFramework_NoCHIPAppProjectConfig
branch
from
d5ca4ab
to
c96b62d
Compare
|
PR #36178: Size comparison from 6f0a70c to c96b62d Full report (67 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Comment on lines
+59
to
+60
| // Default of 8 ECs is not sufficient for some of the unit tests | ||
| // that try to validate multiple simultaneous interactions. |
There was a problem hiding this comment.
This should only matter when building those unit tests, right?
That said, in general we might in fact want more than 8 on darwin.....
There was a problem hiding this comment.
We define CHIP_SYSTEM_CONFIG_POOL_USE_HEAP = 1 so the pool size should be entirely irrelevant according to Pool.h:
template <typename T, size_t N>
class ObjectPool<T, N, ObjectPoolMem::kHeap> : public HeapObjectPool<T> {};
So I think we should just not override CHIP_CONFIG_MAX_EXCHANGE_CONTEXTS at all.
There was a problem hiding this comment.
It looks like this macro is being used to size an array as well.
from src/lib/core/CHIPConfig.h
#define CHIP_CONFIG_MCSP_RECEIVE_TABLE_SIZE (CHIP_CONFIG_MAX_EXCHANGE_CONTEXTS - 2)
from src/protocols/secure_channel/MessageCounterManager.h:
ReceiveTableEntry mReceiveTable[CHIP_CONFIG_MCSP_RECEIVE_TABLE_SIZE];
Comment on lines
+78
to
+79
| #if TARGET_OS_IPHONE | ||
| #define CHIP_CONFIG_KVS_PATH "chip.store" |
There was a problem hiding this comment.
Shouldn't this be for all the cases that are not TARGET_OS_OSX or something?
There was a problem hiding this comment.
When does this actually take effect? The default KVS isn't used from the Framework right?
Also, what's the effect of having a relative paths here?
There was a problem hiding this comment.
Shouldn't this be for all the cases that are not TARGET_OS_OSX or something?
TARGET_OS_IPHONE includes any iOS variant, including tvOS etc (it's terribly named)
There was a problem hiding this comment.
When does this actually take effect? The default KVS isn't used from the Framework right? Also, what's the effect of having a relative paths here?
I assumed it might be used via chip-tool.
Comment on lines
+59
to
+60
| // Default of 8 ECs is not sufficient for some of the unit tests | ||
| // that try to validate multiple simultaneous interactions. |
There was a problem hiding this comment.
We define CHIP_SYSTEM_CONFIG_POOL_USE_HEAP = 1 so the pool size should be entirely irrelevant according to Pool.h:
template <typename T, size_t N>
class ObjectPool<T, N, ObjectPoolMem::kHeap> : public HeapObjectPool<T> {};
So I think we should just not override CHIP_CONFIG_MAX_EXCHANGE_CONTEXTS at all.
Comment on lines
+78
to
+79
| #if TARGET_OS_IPHONE | ||
| #define CHIP_CONFIG_KVS_PATH "chip.store" |
There was a problem hiding this comment.
When does this actually take effect? The default KVS isn't used from the Framework right?
Also, what's the effect of having a relative paths here?
| // The session pool size limits how many subscriptions we can have live at | ||
| // once. Home supports up to 1000 accessories, and we subscribe to all of them, | ||
| // so we need to make sure the pool is big enough for that. | ||
| #define CHIP_CONFIG_SECURE_SESSION_POOL_SIZE 1000 |
There was a problem hiding this comment.
Do we even need to hard-limit the number of secure sessions in this way? SecureSessionTable::EvictAndAllocate does this rather complicated eviction logic... can we just remove the limit and compile out the eviction code entirely? (Probably something for a follow-up change)
There was a problem hiding this comment.
Followup at best; the secure session situation is complicated.
Comment on lines
+78
to
+79
| #if TARGET_OS_IPHONE | ||
| #define CHIP_CONFIG_KVS_PATH "chip.store" |
There was a problem hiding this comment.
Shouldn't this be for all the cases that are not TARGET_OS_OSX or something?
TARGET_OS_IPHONE includes any iOS variant, including tvOS etc (it's terribly named)
vivien-apple
force-pushed
the
MatterFramework_NoCHIPAppProjectConfig
branch
from
c96b62d
to
f24edd3
Compare
|
PR #36178: Size comparison from 4269ff5 to f24edd3 Increases above 0.2%:
Full report (67 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
…atformConfig.h by defautl instead of relying on CHIPProjectAppConfig.h
vivien-apple
force-pushed
the
MatterFramework_NoCHIPAppProjectConfig
branch
from
f24edd3
to
baee8a3
Compare
|
PR #36178: Size comparison from 5eb3cc0 to baee8a3 Increases above 0.2%:
Full report (67 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…atformConfig.h by defautl instead of relying on CHIPProjectAppConfig.h
Problem
Some build flags in
config/ios/CHIPProjectConfig.hare now obsolete. Additionally, a few others could potentially be moved tosrc/platform/Darwin/CHIPPlatformConfig.hfor better organization.