Return-Path: <linux-kernel-owner+w=401wt.eu-S1757967AbXFSLf1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757967AbXFSLf1 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jun 2007 07:35:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755411AbXFSLfU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 19 Jun 2007 07:35:20 -0400
Received: from mtagate8.de.ibm.com ([195.212.29.157]:19235 "EHLO
	mtagate8.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751922AbXFSLfS (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jun 2007 07:35:18 -0400
Subject: Re: [RFC/PATCH] Documentation of kernel messages
From: holzheu <holzheu@linux.vnet.ibm.com>
Reply-To: holzheu@linux.vnet.ibm.com
To: Arjan van de Ven <arjan@infradead.org>
Cc: Gerrit Huizenga <gh@us.ibm.com>, Jan Kara <jack@suse.cz>,
       Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       randy.dunlap@oracle.com, gregkh@suse.de, mtk-manpages@gmx.net,
       schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
       "lf_kernel_messages@linux-foundation.org" 
	<lf_kernel_messages@linux-foundation.org>,
       pavel@ucw.cz
In-Reply-To: <1182216982.3014.1.camel@laptopd505.fenrus.org>
References: <E1HzGkR-0008DO-Un@w-gerrit.beaverton.ibm.com>
	 <1182171354.11400.40.camel@localhost.localdomain>
	 <1182172374.28566.1.camel@laptopd505.fenrus.org>
	 <1182174836.11400.64.camel@localhost.localdomain>
	 <1182216982.3014.1.camel@laptopd505.fenrus.org>
Content-Type: text/plain
Organization: IBM
Date: Tue, 19 Jun 2007 13:31:22 +0200
Message-Id: <1182252682.11540.32.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-27.rhel4.6) 
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1536
Lines: 45

On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:

<snip>

> well.... surely the messages are caught by some userspace program,
> right? (like syslog).. that can do the lookup and make it all
> conveniently lookup-able and cross-referencable etc etc....

Ok, I agree. Maybe that's really a good idea!

So what about the following proposal:

* Use printk format strings as message IDs
* Use kernel-doc (or similar mechanism) for message documentation
* Use Subsystem tag/component ID for each printk. This might be
  optional, but would make sense to get messages more unique.
* Implement a new tool (kmsg) to allow operators
  to access kernel message descriptions in a convenient way.

The kmsg tool will read the dmsg buffer together with the list of
documented printks, which has been created in the kernel build using
the format strings defined in the KMSG_DOC macros. It matches the known
format strings to the dmesg messages and informs the operator, for
which message he can get a description.

Something like:

>> kmsg
Linux version 2.6.9-42.0.3.ELsmp...
....
[<ID>] lp0 on fire

>> kmsg <ID>
Desciption: your printer failed basic tests, you should check cabling

The <ID> is generated by the kmsg tool and could be e.g. the hashes for
the matching format strings.

Michael

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/