On Tue 2019-03-12 14:19:56, John Ogness wrote: > On 2019-03-12, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > >>> But it doesn't turn SMP system into UP. > >> > >> In this example it turned it into a brick. > >> > >> The problems I see are: > >> > >> 1. The current loglevels used in the kernel are not sufficient to > >> distinguish between emergency and informational messages. Addressing > >> this issue may require things like using a new printk flag and > >> manually marking the printks that we(?) decide are critical. I was > > Perhaps it would be nice if an administrator could additionally "mark" > what _they_ consider critical, i.e. they are aware of and accept the > consequences of a synchronous printk for certain messages. When I look > at things like dynamic_printk and ftrace, I see mechanisms that provide > excellent runtime tuning without much complexity. > > We could extend dynamic_printk to include all printk messages and also > support the emergency classification. We could have something like > ftrace-events, where certain _events_ (i.e a group of printk messages) > could be classified as an emergency (for example, a WARN_ON event, a > watchdog event, a general stacktrace event, etc.). > > These are just ideas that I'm bouncing around my brain. But as you said, > only the administrator can know what is important. So perhaps we need to > provide the administrator an interface to specify that. Interesting idea. But I am very sceptical about it. I can't imagine that anyone would like to configure 100k messages or so. It is even worse than kernel configuration. And the trend is to avoid config options where possible. It is because it is almost impossible to understand all existing options and make qualified decisions. And it is hard to expect that users would be able to make a better decision than a developer who implemented the code behind the option. Our discussion is a nice example. Even we have troubles to understand all consequences of different approaches. Even if we reach a conclusion and document it. Then nobody would want to read several pages long tutorial how to configure printk ;-) Best Regards, Petr -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
