Lora: Remove singleton pattern #6692
Conversation
|
@AnttiKauppila, @hasnainvirk, @kjbracey-arm please review. |
| 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; | ||
| LoRaMacCrypto::LoRaMacCrypto() | ||
| { | ||
| memset(mic_block_b0, 0, sizeof(mic_block_b0)); |
There was a problem hiding this comment.
Could avoid explicit memsets by zero-initting arrays like any other element:
LoRaMacCrypto::LoRaMacCrypto() : mic_block_b0(), a_block(), ...
You will still need to manually set the non-zero elements though (with current C++03).
There was a problem hiding this comment.
Ok. I'll change this.
features/lorawan/LoRaWANStack.h
Outdated
| @@ -70,7 +70,8 @@ class LoRaWANStack: private mbed::NonCopyable<LoRaWANStack> { | |||
| } device_states_t; | |||
|
|
|||
| public: | |||
| static LoRaWANStack& get_lorawan_stack(); | |||
| LoRaWANStack(); | |||
| ~LoRaWANStack(); | |||
There was a problem hiding this comment.
I can't see any reason to be defining an empty destructor here. Yes, it's an existing pattern, but tidy up?
There was a problem hiding this comment.
Ok, I'll remove the empty destructor as this class is not supposed to be herited.
| int encrypt_payload(const uint8_t *buffer, uint16_t size, const uint8_t *key, | ||
| uint32_t address, uint8_t dir, uint32_t seq_counter, | ||
| uint8_t *enc_buffer); | ||
| #define LORAMAC_MIC_BLOCK_B0_SIZE 16 |
There was a problem hiding this comment.
Not a fan of this define - it's uniquely specified in one place - sizeof mic_block_b0. You can just use that to reference, and the size of the mic_block is obviously where it's defined: mic_block_b0[16].
(I often try to avoid excessive defines, having been traumatised by a source file that had 100 lines like this:
HW_REG_A = REG_A_INIT_VALUE;
HW_REG_B = REG_B_INIT_VALUE;
Yay, pointless indirection. Don't need a define for a constant that occurs in exactly 1 place, unless you need to expose it as a config option.)
| int decrypt_payload(const uint8_t *buffer, uint16_t size, const uint8_t *key, | ||
| uint32_t address, uint8_t dir, uint32_t seq_counter, | ||
| uint8_t *dec_buffer); | ||
| #define LORAMAC_AES_CMAC_KEY_LENGTH 16 |
There was a problem hiding this comment.
On a similar note, this wouldn't be needed if you passed the key length as a parameter to compute_mic, and that's sizeof nwk_skey. Would actually be a bit tighter. Or the key could actually be a proper type - a struct with a 16-byte array in it, so you can use sizeof inside compute_mic.
|
Review jenkins CI failures, related |
|
CI failure was caused by missing constructor when LoRa was built with missing mbedtls configurations. I'll fix this. |
|
@kjbracey-arm please review again. |
|
Please review docs failure in Travis CI |
|
@0xc0170 For some reason Doxygen started to complain about the Semtech's header even though I didn't modify it. But this is now fixed. |
| @@ -542,6 +544,11 @@ class LoRaMac { | |||
| */ | |||
| LoRaMacChannelPlan channel_plan; | |||
|
|
|||
| /** | |||
| * Channel planning subsystem | |||
There was a problem hiding this comment.
Its a crypto subsystem
In order to get rid of static variables, LoRaCrypto functionality is now in a C++ class.
After changing LoRaMacCrypto as C++ class, we no longer have static variables in LoRa implementation. Therefore singleton pattern can be removed.
|
@hasnainvirk Text fixed. |
|
/morph build |
Build : SUCCESSBuild number : 1818 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1463 |
|
@0xc0170 Could you restart the test? This failure does not seem to be related to this PR. |
|
/morph test |
Description
LoRaMacCrypto was the last source that was not yet converted to a C++ class. Since that is now a C++ class, also singleton pattern can be removed from LoRa stack. This will simplify the code and enable easier tracking of memory consumption and further refactorings.
Pull request type
[ ] Fix
[X] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change