On Mon, Oct 20, 2025 at 02:36:11PM +0200, Jonas Rebmann wrote: > Hi Sascha, > > On 2025-10-20 11:36, Sascha Hauer wrote: > > > If loglevels are selected using -l or -p in addition to cleaning being > > > selected using -c, only clean those messages shown by the loglevel > > > selection. > > > > I find this behaviour rather surprising. The only useful thing I could > > think of we can do with this is "Discard unimportant messages", but only > > by printing them. It would be more useful if we had a -C (uppercase) > > option to discard messages without printing them. But even with that, > > there are many things we can do with this behaviour that are not useful > > and only a few that are actually useful. We could delete for example all > > "info" messages and keep the more and less important messages, but why > > would we want to do this? > > > I think you should rather use the filter options -l and -p to limit the > > output to the messages you are interested in and finally use -c to clear > > the buffer. > > I think both behaviors could come as a surprise depending on how you > look at it but if no one raises another position, I can make sure that > in v2, -c will always clear all messages of all loglevels which is also > much closer to the current behavior. I'd then add a warning that in > these cases, filtered-out messages are cleared without being shown.
At least clearing all messages would be in line with dmesg -c in Linux. > > However I disagree about the -C option and the idea of clearing in a > separate step. > > My concept of -c is that it 'consumes' the ringbuffer, a 'dequeue' > operation, if you will. This needs to be a single step to ensure that no > messages get lost or duplicated. > > For example in some long-running test, you might run `dmesg -c` > periodically and store the output. It should be guaranteed that when > doing this, you never loose a single log message (if you clear often > enough to never fill/overflow the buffer). I think the prior > implementation couldn't guarantee that, but my patch changes that. From > that perspective, the option to clear the buffer in a separate step > would not help. I rather meant while using dmesg interactively. For the long-running test I agree, we shouldn't lose log messages in this case, but Ahmad provided a way to archieve this. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
