You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/03/24 14:11:06 UTC

[GitHub] [incubator-nuttx] v01d opened a new issue #3166: dmesg/ramlog: do not clear by default but add option to do so

v01d opened a new issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166


   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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d edited a comment on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
v01d edited a comment on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-808235871


   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:
   - `-C`: clear buffer
   - `-w`: print contents and wait for new messages (open in blocking mode)
   
   What do you think about these modifications?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-808847933


   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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
v01d commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-808965495


   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?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-822474037


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


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-808847933


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


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
v01d commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-822472387


   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. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-822281024


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


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-822281024


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


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] v01d commented on issue #3166: dmesg/ramlog: do not clear by default but add option to do so

Posted by GitBox <gi...@apache.org>.
v01d commented on issue #3166:
URL: https://github.com/apache/incubator-nuttx/issues/3166#issuecomment-808235871


   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. 
   
   What do you think about these modifications?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org