-
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
Implement simple access control cluster persistence/storage #10251
Comments
PR #11550 adds an in-memory implementation that uses a single array of POD "storage" structs for the entry data. That format is already quite terse. Therefore, what mainly needs to happen here:
Probably wise to consider some kind of mini header for the flash storage, containing a version etc. |
@harimau-qirex is putting the simple approach (down in access control module) in PR #14253 so we can have some persistence in the interim, then will refactor it out into the cluster with improved storage format and more use of generated code (issue #14451). |
The remaining work is for each platform to call chip::Access::Examples::SetAccessControlDelegateStorage (defined in src/access/examples/ExampleAccessControlDelegate.h) with a PersistentStorageDelegate implementation. Linux and MacOS call this in examples/platform/linux/AppMain.cpp with an implementation of PersistentStorageDelegate backed by the KVS manager. The keys passed into the PersistentStorageDelegate are defined in src/lib/support/DefaultStorageKeyAllocator.h as AccessControlList and AccessControlEntry. By default there are 48 entries (numbered 0-47), but that is configurable by setting CHIP_CONFIG_MAX_DEVICE_ADMINS and CHIP_CONFIG_EXAMPLE_ACCESS_CONTROL_MAX_ENTRIES_PER_FABRIC. |
The text was updated successfully, but these errors were encountered: