Add generic API to retrieve provisioned data from BSP#2192
Add generic API to retrieve provisioned data from BSP#2192andrzej-kaczmarek wants to merge 4 commits intoapache:masterfrom
Conversation
andrzej-kaczmarek
changed the title
| * If provided buffer is too small to store all provisioned data, returned data | ||
| * may be either truncated (check \p length to see complete data length) or | ||
| * error is returned. The former can usually happen for variable-length data | ||
| * where application should first query data length, the latter can usually | ||
| * happen for fixed-length data where data length is well known. |
There was a problem hiding this comment.
This is just a personal thing, but I dislike it when a library makes me do extra work to check for truncation. I prefer it when it is always an error if the supplied buffer is too small. I could be mistaken, but looking at the list of data types, I don't see any that can be safely truncated.
One alternative would be to have a second function that allows truncation.
Just my two cents.
There was a problem hiding this comment.
I guess I have a comment similar to Chris's comment although maybe not sure. There is a case where the length after calling this function may be greater than the input length? That does seem a bit confusing to me although I guess the intent there is to tell you things got truncated. I guess if we decide to not truncate that will go away. So I guess this means I agree with Chris? :-)
| len = cnt; | ||
|
|
||
| cnt = min(sizeof(NRF_FICR->DEVICEADDR), max_len - len); | ||
| cnt = max(0, cnt); |
There was a problem hiding this comment.
Line 53 seems not to improve anything
line 48: cnt <= max_len
line 50: len = cnt, so: len <= max_len
line 52: max_len - len >= 0 so: cnt >= 0
hence line 53 is not needed if could be useful after line 48 in case max_len was negative to prevent damage in memcpy
Currently we only have dedicated API to retrieve HW ID from BSP. However, there are more data that can be provisioned to device and it would be nice to be able to retrieve it in a consistent way regardless of BSP used. This patch adds generic API to retrieve provisioned data. Note that it does not specify how these data should be provisioned to device, it's just about reading them. There are few predefined data identifiers and this list can be extended as there are more data that are usable by various packages. Also there is separate range for user-defined identifiers. In general provisioned data are BSP-specific but application can provide own callback to override some data or support custom data identifiers via the same common API.
This converts existing hal_bsp APIs to get hw id into MCU APIs. The hal_bsp APIs are still there for backwards compatibility and they just are wrappers for MCU APIs.
Use hal_bsp_prov_data instead.
|
@ccollins476ad @wes3 you're right, this is too confusing. my intention was to allow to read some data even if app uses some buffer of hardcoded length and it's too small, but this does not really make sense as incomplete data are not really useful... I changed this API to return data length as previously, but if buffer is too small it will always return an error. so caller does not need to check for truncation since this won't happen. also I included some code in common hal_bsp.c so each BSP does not need to implement it (i.e. c&p...) I keep this as a draft for now since I am still not really sure if this does what I would expect, so any comments regarding usability of this API are welcome :) |
andrzej-kaczmarek
force-pushed
the
bsp-prov-data
branch
from
63b711b to
d73f885
Compare
Style check summaryNo suggestions at this time! |
5 participants
No description provided.