On Thu, May 20, 2021 at 04:35:45PM +0000, Song Liu wrote: > > > > On May 20, 2021, at 12:08 AM, Dmitrii Banshchikov <me@xxxxxxxxxxxxx> wrote: > > > > On Wed, May 19, 2021 at 10:32:25AM -0700, Song Liu wrote: > >> On Tue, May 18, 2021 at 11:05 PM Dmitrii Banshchikov <me@xxxxxxxxxxxxx> wrote: > >>> > >>> There are three logging levels for messages: FATAL, NOTICE and DEBUG. > >>> When a message is logged with FATAL level it results in bpfilter > >>> usermode helper termination. > >> > >> Could you please explain why we choose to have 3 levels? Will we need > >> more levels, > >> like WARNING, ERROR, etc.? > > > > > > I found that I need one level for development - to trace what > > goes rignt and wrong. At the same time as those messages go to > > dmesg this level is too verbose to be used under normal > > circumstances. That is why another level is introduced. And the > > last one exists to verify invariants or error condintions from > > which there is no right way to recover and they result in > > bpfilter termination. > > /dev/kmsg supports specifying priority of the message. Like: > > echo '<4> This message have priority of 4' > /dev/kmsg > > Therefore, with proper priority settings, we can have more levels safely. > Does this make sense? Yes, it makes. BPFILTER_FATAL should be renamed to BPFILTER_EMERG to match printk() counterpart. All bpfilter log levels should match printk() levels. All bpfilter log messages should include log level. And BPFILTER_DEBUG should be easily turned on/off during compilation to enable tracing/debug. > > Thanks, > Song > > [...] > -- Dmitrii Banshchikov
