Confusing length handling in nrf_log_frontend.c

RE: Confusing length handling in nrf_log_frontend.c

Jørgen Holmefjord — Wed, 18 Nov 2020 15:59:49 GMT

I understand your concern and have added your comment to the internal report.

RE: Confusing length handling in nrf_log_frontend.c

Vincent Belaïche — Wed, 18 Nov 2020 15:33:07 GMT

FYI, the reason why I had to look into this code is because I am currently investigating some bug, and one of the symptom is logging not working as expected in some circumstances.

Concerning my comment, that was not only a matter of code clarity. If you have code like this :

nrf_log_header_t * p_header = (nrf_log_header_t *)&m_log_data.buffer[header_wr_idx & mask];
p_header->base.hexdump.severity = severity_mid & NRF_LOG_LEVEL_MASK;
p_header->base.hexdump.offset = 0;
p_header->base.hexdump.len = length;
p_header->base.hexdump.type = HEADER_TYPE_HEXDUMP;
p_header->base.hexdump.in_progress = 0;

Then you rely on the compiler to make the p_header->base.raw word written as an atomic 32bit operation into the circular buffer, which is desirable, as the writing may occur in a different task than the flushing when logging is differed.

I think that there is no problem with the current code (because the compiler will probably optimise all the field accesses in register only operation before push all fields in a single 32bit word to the memory), however, even though the in_progress field is set last, such kind of coding, relying on the compiler goodness, is per se problematic : that is why I made this patch, so as to be 200% that the issue is on our side.

RE: Confusing length handling in nrf_log_frontend.c

Jørgen Holmefjord — Wed, 18 Nov 2020 14:07:56 GMT

Hi,

Than you for posting your suggestions. I confirmed with the developers that they agree that this will make the code more readable.

I have created an internal report, it will be considered for future releases.

Best regards,
Jørgen

RE: Confusing length handling in nrf_log_frontend.c

Vincent Belaïche — Mon, 16 Nov 2020 14:02:27 GMT

devzone.nordicsemi.com/.../nordic_2D00_suggestion.diff

To be a little more specific I attached a patch file.