linux-kernel - Re: [patch 1/3] kmsg: Kernel message catalog macros.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Aug 2008 20:06:30 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Tim Hockin <thockin@...kin.org>
Cc:	Greg KH <gregkh@...e.de>, Joe Perches <joe@...ches.com>,
	linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
	lf_kernel_messages@...ts.linux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Holzheu <holzheu@...ibm.com>,
	Gerrit Huizenga <gh@...ibm.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Jan Kara <jack@...e.cz>, Pavel Machek <pavel@....cz>,
	Sam Ravnborg <sam@...nborg.org>,
	Jochen Voß <jochen.voss@...glemail.com>,
	Kunai Takashi <kunai@...ux-foundation.jp>,
	Tim Bird <tim.bird@...sony.com>
Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros.

On Fri, 2008-08-15 at 10:03 -0700, Tim Hockin wrote:
> On Fri, Aug 15, 2008 at 9:03 AM, Greg KH <gregkh@...e.de> wrote:
> >> I'd like to be able to report something like an OOM kill in (roughly)
> >> the same way as an ATA error, and I want (though could be talked out
> >> of) a way to tell these "events" (for lack of a better word) apart
> >> from plain-old-printk()s.
> >
> > That's great, then create something that can handle both!  Don't throw
> > away some wonderful information that way over half the kernel has access
> > to just because the minority doesn't.  That would mean that we would
> > loose information in those drivers overall.
> 
> Sorry, I never meant to imply that dev_printk() was to be ignored, my
> examples was meant to be trivial to demonstrate :)  dev_printk() is
> good.  We should keep it :)

The invention of dev_printk was a good thing. It adds structure to the
messages if it is about a device. Before we had a simple printk that did
or did not include information about the device driver and the device
name. dev_printk makes sure that this information is always added.
BUT, what dev_printk does not do is to make sure that the message can be
uniquely identified so that the description of the message can be found
in the message catalog. Our approach is to combine the driver name and a
simple index into a message tag. The original dev_printk remains almost
unchanged. A typical hunk in the code looks like this:

@@ -24,8 +27,8 @@ static int zfcp_ccw_probe(struct ccw_dev

        down(&zfcp_data.config_sema);
        if (zfcp_adapter_enqueue(ccw_device)) {
-               dev_err(&ccw_device->dev,
-                       "Setup of data structures failed.\n");
+               kmsg_dev_err(73, &ccw_device->dev,
+                            "Setup of data structures failed.\n");
                retval = -EINVAL;
        }
        up(&zfcp_data.config_sema);

The kmsg_dev_printk still has almost the same structure, only the
message id is added. There is one real difference though:
the driver name is specified with KMSG_COMPONENT and not via
dev_driver_string(dev). We do that so that the kmsg-doc script can
actually find the driver name. The dev_driver_string(dev) is dynamic and
a static tool has a hard time to find the actual driver string.  

-- 
blue skies,
  Martin.

"Reality continues to ruin my life." - Calvin.

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