linux-kernel - Re: [RFC/PATCH] Documentation of kernel messages

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1181809023.5446.14.camel@localhost>
Date:	Thu, 14 Jun 2007 10:17:03 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Greg KH <gregkh@...e.de>
Cc:	holzheu <holzheu@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org,
	randy.dunlap@...cle.com, akpm@...l.org, mtk-manpages@....net,
	heiko.carstens@...ibm.com
Subject: Re: [RFC/PATCH] Documentation of kernel messages

On Wed, 2007-06-13 at 11:32 -0700, Greg KH wrote:
> > > So, why not use what we already have and work off of it?
> > 
> > dev_printk() and friends are great, since they already define
> something
> > like KMSG_COMPONENT: The driver name.
> 
> They provide way more than that, they also provide the explicit device
> that is being discussed, as well as other things depending on the
> device.

dev_printk() and friends provide additional information for a printk
that is related to a device. Not every printk is about a device, so I
think Michaels proposal is orthorgonal to dev_printk. We definitly
should have a dev_printk variant that uses the kmsg documentation tag
AND we should have a normal printk variant as well that uses the kmsg
tagging.

> So if you are going to do this, please use the already-in-place macros
> to hook into, don't try to get the driver authors to pick up something
> new and different, as it's going to be _very_ difficult, trust me...

There is no doubt that it will be difficult to get a larger part of the
developers use the kmsg scheme (e.g. see the reaction of Dave M.). We do
not have the illusion that we can replace every single message in the
kernel, nor do we think that it would make sense to do so. What we would
do for s390 is to check each message in drivers/s390 and think hard if
the message should be 1) removed, 2) replaced with a {dev_}printk_kmsg
or 3) left as it is. Fortunatly for us there are not too many drivers
for s390 ..

-- 
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/