Re: [RFC] New kernel-message logging API

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Vegard Nossum <vegard.nossum@...>
Cc: LKML <linux-kernel@...>, holzheu <holzheu@...>, Joe Perches <joe@...>, Rob Landley <rob@...>, Dick Streefland <dick.streefland@...>
Date: Saturday, September 22, 2007 - 9:05 pm

On 9/22/07, Vegard Nossum <vegard.nossum@gmail.com> wrote:

Nice. I would suggest having some kind of standard way to show the
information on the screen/dmesg. I mean, instead of having plain lines
being written to the log, having something very short like:

SSL: Message sent.

Being:

SS - Subsystem ("EA"  for early code, "MM" for memory managment, "PU"
for processor stuff, "HD" for hard disks, "PP" for parallel port, "NT"
for networking, "VI" for video stuff, "FB" for framebuffers, "SN" for
sound stuff, "KE" for keyboard, "MO" for mouse, ... I think you get
the idea, just generic things).
L - Log level (0 for emerg, ..., 7 for debug)

And maybe some other character for other information. This would be
great to read pretty easily dmesg and for grepping, like:

  $ dmesg | grep ^FB

for getting just information about framebuffers, or

  $ dmesg | grep ^..[0123]

to get all the problems of the whole kernel/system.

So, for example, userspace scripts will be able to separate into
different log files the kernel stuff:

  #!/bin/sh
  dmesg | grep ^..[0123] > klog.errors
  dmesg | grep ^NT > klog.networking
  dmesg | grep ^HD > klog.harddisks
  dmesg | grep ^FB > klog.framebuffers

Maybe its weird at first, but I think it will speed up the reading of
plain dmesg's outputs for everyone at the cost of 3-5 more characters
at every line in dmesg.

Also, it may help to make printk()'s messages to be more uniform,
instead of having every .c file having differents ways to express
similar things.

Getting more complex, lets add another character:

SSLR: Message sent.

being R the reason of the message (D for information about a
probed-and-detected hardware [like a PCI card], R for a new
succesfully registered device [like a framebuffer], S for new settings
in a device [like taking up a ethernet link, or that messages about
IRQs], C for copyright/about/info lines, ...).

Now we have at some dmesg (for example):

  eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
  ieee80211_crypt: registered algorithm 'TKIP'
  ipw3945: Intel(R) PRO/Wireless 3945 Network Connection 1.2.2d
  ipw3945: Copyright(c) 2003-2006 Intel Corporation
  ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
  PCI: Setting latency timer of device 0000:0c:00.0 to 64
  ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
  ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
  usb 6-1: new low speed USB device using uhci_hcd and address 2
  usb 6-1: configuration #1 chosen from 1 choice
  usbcore: registered new interface driver hiddev

and we could have:

  NT6R eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
  NT6R ieee80211_crypt: algorithm 'TKIP'
  NT6C ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver 1.2.2d
  NT7C ipw3945: Copyright(c) 2003-2006 Intel Corporation
  XX6S ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
  XX6S PCI: Latency timer of device 0000:0c:00.0 to 64
  NT6R ipw3945: Intel PRO/Wireless 3945ABG Network Connection
  NT6D ipw3945: geography ABG (13 802.11bg channels, 23 802.11a channels)
  US6R usb 6-1: low speed USB device using uhci_hcd and address 2
  US6S usb 6-1: configuration #1 chosen from 1 choice
  US6R usbcore: new interface driver hiddev

which I think its much more clear... Wanna know about registered
networking-related devices? Then grep using "^NT.R":

  NT6R eth0: Broadcom 4400 10/100BaseT Ethernet 00:1f:a2:0c:4a:72
  NT6R ieee80211_crypt: algorithm 'TKIP'
  NT6R ipw3945: Intel PRO/Wireless 3945ABG Network Connection

...

Nothing more, thanks for reading :)

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] New kernel-message logging API, Vegard Nossum, (Sat Sep 22, 3:27 pm)
Re: [RFC] New kernel-message logging API, Jesse Barnes, (Mon Sep 24, 2:26 pm)
Re: [RFC] New kernel-message logging API, Michael Holzheu, (Mon Sep 24, 5:22 am)
Re: [RFC] New kernel-message logging API, Joe Perches, (Mon Sep 24, 11:19 am)
Re: [RFC] New kernel-message logging API, Michael Holzheu, (Tue Sep 25, 4:57 am)
Re: [RFC] New kernel-message logging API, Rob Landley, (Mon Sep 24, 7:51 pm)
Re: [RFC] New kernel-message logging API, Joe Perches, (Mon Sep 24, 8:10 pm)
Re: [RFC] New kernel-message logging API, Rob Landley, (Mon Sep 24, 9:46 pm)
Re: [RFC] New kernel-message logging API, Vegard Nossum, (Mon Sep 24, 12:43 pm)
Re: [RFC] New kernel-message logging API, Joe Perches, (Mon Sep 24, 1:00 pm)
Re: [RFC] New kernel-message logging API, Vegard Nossum, (Mon Sep 24, 4:37 pm)
Re: [RFC] New kernel-message logging API, Rob Landley, (Mon Sep 24, 9:18 pm)
Re: [RFC] New kernel-message logging API, Rob Landley, (Sun Sep 23, 4:05 pm)
Re: [RFC] New kernel-message logging API, Miguel Ojeda, (Sat Sep 22, 9:05 pm)
Re: [RFC] New kernel-message logging API, Vegard Nossum, (Tue Sep 25, 1:27 am)
Re: [RFC] New kernel-message logging API, Miguel Ojeda, (Tue Sep 25, 1:24 pm)
Re: [RFC] New kernel-message logging API, Joe Perches, (Sat Sep 22, 8:13 pm)
Re: [RFC] New kernel-message logging API, Vegard Nossum, (Sun Sep 23, 4:39 am)
Re: [RFC] New kernel-message logging API, Joe Perches, (Sun Sep 23, 3:25 pm)
Re: [RFC] New kernel-message logging API, Jan Engelhardt, (Sun Sep 23, 4:45 am)
Re: [RFC] New kernel-message logging API, Joe Perches, (Sun Sep 23, 3:23 pm)
Re: [RFC] New kernel-message logging API, Vegard Nossum, (Sun Sep 23, 5:20 am)
Re: [RFC] New kernel-message logging API, Jan Engelhardt, (Sun Sep 23, 5:38 am)
Re: [RFC] New kernel-message logging API, Kyle Moffett, (Sat Sep 22, 8:40 pm)
Re: [RFC] New kernel-message logging API, Joe Perches, (Sat Sep 22, 8:47 pm)
Re: [RFC] New kernel-message logging API, Kyle Moffett, (Sat Sep 22, 11:43 pm)