[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0707091559x7103fea6vc74c06f451e66d55@mail.gmail.com>
Date: Tue, 10 Jul 2007 04:29:01 +0530
From: "Satyam Sharma" <satyam.sharma@...il.com>
To: "Oliver Neukum" <oliver@...kum.org>
Cc: "Kunai, Takashi" <kunai@...ux-foundation.jp>,
holzheu@...ux.vnet.ibm.com, "Rob Landley" <rob@...dley.net>,
"Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
lf_kernel_messages@...ux-foundation.org, mtk-manpages@....net,
jack@...e.cz, randy.dunlap@...cle.com, gregkh@...e.de,
pavel@....cz, tim.bird@...sony.com, gh@...ibm.com,
arjan@...radead.org, sam@...nborg.org, jengelh@...putergmbh.de,
hpa@...or.com, joe@...ches.com, auke-jan.h.kok@...el.com,
hansendc@...ibm.com, davem@...emloft.net, Valdis.Kletnieks@...edu,
kenistoj@...ibm.com, schwidefsky@...ibm.com,
heiko.carstens@...ibm.com
Subject: Re: Documentation of kernel messages (Summary)
On 7/9/07, Oliver Neukum <oliver@...kum.org> wrote:
> Am Montag, 9. Juli 2007 schrieb Kunai, Takashi:
> > (b)printk hashes and (c)Format strings. (a) seems difficult to get
> > supports from kernel developers and (c) lacks uniqueness of each
> > message. Though (b) also lacks uniqueness, adding component id and/or
>
> We have generators for hash functions that guarantee unique results
> for a set of inputs.
Right, perfect hash generators require the input set to be known
*a priori*.
> They are even GPLed. As you are operating against
> a known target, that should work.
But, I'm not sure they'd be operating against a known target -- I don't
really know what exactly would be hashed, but if it's kernel printk()
messages (the format string, obviously), then please remember that
new messages would get added all the time, and unless we're also
willing to change the hash function every time a printk() gets added
to the kernel (whew!) it's going to be a problem -- especially because
we don't really want to generate new hash functions for every kernel
version / or for every kernel build, because we'd obviously like the
same error message to hash to the same value across versions.
If we really care about uniqueness, the only solution I see is to use
a strong/cryptographic hash function (say SHA-1, which would never
change in the future) that generates the hashes for all the printk()
messages that are getting compiled-in at build-time ... but it would be
slow, of course.
Satyam
-
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/
Powered by blists - more mailing lists