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 23:39:03 -0400 (EDT)
From:	Rick Troth <rmt@...ita.net>
To:	Tim Hockin <thockin@...kin.org>
cc:	schwidefsky@...ibm.com, Rusty Russell <rusty@...tcorp.com.au>,
	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>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Jan Kara <jack@...e.cz>, Pavel Machek <pavel@....cz>,
	Sam Ravnborg <sam@...nborg.org>, Joe Perches <joe@...ches.com>,
	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.

This is really an easy thing to do.
It can be achieved without a huge retro-fit.
It can happen even without yet another macro.
(Not saying that there should not be a new macro or new function,
just that we can enjoy unique message IDs without those mechanisms.)

Martin Schwidefsky said:
> > Ok, so  a specialized version of printk will do the work to calculate
> > the hash. Only, what will we do if there ever is a conflict? The message
> > tag has to be unique. The shorter the hash is, the more likely a
> > collision gets. Don't know if 6 hash digits is enough to just ignore the
> > problem.

Point to note: the message tag has to be unique.
The tag is what's relevant, what gets catalogued.

I don't really see the value of a hash per se.
What Martin has suggested (unless I have misunderstood) is
the driver name combined with some index number ==> unique msg id.
That's not exactly a "hash".  (One can generate a hash from it,
but why bother?  You've got a unique string already.)

Then Tim Hockin wrote:
> And if you ever need to change the text that is in the format string?
> The hash changes.  That seems exactly counter to your goal...

Whether hashed or not, what's needed is premeditated reporting,
intentional dividing between variable content (like device ID)
and the explanatory text arround it.  Prefix each line with a token
(or as most are calling it, a "tag") that can be looked up off-line.

I hope no one is thinking gettext in this thread.
Don't clutter the kernel with something like gettext.

And don't burden the kernel with run-time text crunching.
Message codes go in when the module is written.
They get looked up either in user space or off-line.
Easy!  Almost trivial!

-- R;   <><

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