search

apache / nuttx

Apache NuttX is a mature, real-time embedded operating system (RTOS)
https://nuttx.apache.org/
Apache License 2.0
2.83k stars 1.17k forks source link

dmesg/ramlog: do not clear by default but add option to do so #3166

Open protobits opened 3 years ago

protobits commented 3 years ago

We could improve dmesg by only clearing ring buffer when specified by adding support for a -C option, as in Linux. This way the default works more as expected. I think this requires some change on nuttx side (besides just adding the option to dmesg command), so i'm creating the issue here for now.

protobits commented 3 years ago

I'm looking at RAMLOG and I would do the following modifications:

  1. remove CONFIG_RAMLOG_NONBLOCKING option and use O_NONBLOCK received during open() to determine blocking/non-blocking mode
  2. make the read() non-destroying (just allow to read ramlog contents without clearing it)
  3. use can control manual clearing by opening file with O_TRUNC option and close it
  4. make ramlog_read() do buffer copy instead of char-by-char loop. Any reason this is done this way? I think char-by-char write could make sense given that it can be called from interrupt handler (is that why?). But at least read() should not have that problem.

I further think that supporting no buffer overwrite does not really make sense: if one wants to ensure messages are not lost either the buffer should be made bigger or a non-volatile support be used.

With these changes, we can have dmesg handle these options:

What do you think about these modifications?

xiaoxiang781216 commented 3 years ago

The suggestion looks good. But it's also useful to support syslog_channel_s::sc_write since it could avoid the log interlace issue discussed here: https://github.com/apache/incubator-nuttx/pull/3050.

protobits commented 3 years ago

That part might be trickier since I still don't understand how to safely change it into a simple copy. It appears it deliberately does char-by-char to ensure safety of the internal ring buffer without using a mutex. Is that so?

xiaoxiang781216 commented 3 years ago

@v01d when do you have free time to implement this feature? We like all of them:).

protobits commented 3 years ago

Sorry, I will get to this later on. I'm currently knee deep into CMake migration (currently trying to support sim build) so that I can open a draft PR soon.

xiaoxiang781216 commented 3 years ago

Ok, If I find the free time, I will take this work.