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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 14 Jun 2007 14:26:39 +0200
From:	Jan Kara <jack@...e.cz>
To:	holzheu <holzheu@...ux.vnet.ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com,
	gregkh@...e.de, mtk-manpages@....net, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com,
	"lf_kernel_messages@...ux-foundation.org" 
	<lf_kernel_messages@...ux-foundation.org>
Subject: Re: [RFC/PATCH] Documentation of kernel messages

On Thu 14-06-07 13:47:41, holzheu wrote:
> On Thu, 2007-06-14 at 12:38 +0200, holzheu wrote:
> > On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
> > >   <snip>
> > > 
> > > > Your proposal is similar to one I made to some Japanese developers
> > > > earlier this year.  I was more modest, proposing that we
> > > > 
> > > > - add an enhanced printk
> > > > 
> > > > 	xxprintk(msgid, KERN_ERR "some text %d\n", some_number);
> > >   Maybe a stupid idea but why do we want to assign these numbers by hand?
> > > I can imagine it could introduce collisions when merging tons of patches
> > > with new messages... Wouldn't it be better to compute say, 8-byte hash
> > > from the message and use it as it's identifier? We could do this
> > > automagically at compile time.
> > 
> > Of course automatically generated message numbers would be great and
> > something like:
> > 
> > hub.4a5bcd77: Detected some problem.
> 
> Sorry, I first read: 8 characters not 8 bytes.
> 
> Indeed, "hub.d41d8cd98f00b204: Detected some problem." ... does not look
> like very beautiful.
> 
> But maybe also 4 bytes would be enough, since the hash only has to be
> unique within one component e.g. "hub".
  It depends how large components you expect. For example for 10000
messages there is already 1% probability of collision so it means sooner or
later we are going to hit it... For 1000 messages the probability is
roughly 0.1% which is still not so small that I'd be comfortable with it.
On the other hand we could use something like gperf to generate perfect
hashing function and then we don't have to worry about colisions.

									Honza
-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
-
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/