linux-kernel - Re: [patch 3/3] kmsg: convert xpram messages to kmsg api.

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]

Message-ID: <20080807170310.GC9214@suse.de>
Date:	Thu, 7 Aug 2008 10:03:10 -0700
From:	Greg KH <gregkh@...e.de>
To:	Martin Schwidefsky <schwidefsky@...ibm.com>
Cc:	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>, 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 3/3] kmsg: convert xpram messages to kmsg api.

On Thu, Aug 07, 2008 at 10:39:13AM +0200, Martin Schwidefsky wrote:
> On Wed, 2008-08-06 at 13:11 -0700, Greg KH wrote:
> > > > > > > +#define KMSG_COMPONENT "xpram"
> > > > > > 
> > > > > > Can't you just use KBUILD_MODULE_NAME instead?  That makes it one less
> > > > > > thing you have to define in the code (and forget about when moving files
> > > > > > around or cut-and-pasting).
> > > > > 
> > > > > Two reason why we don't want to use KBUILD_MODULE_NAME:
> > > > > 1) the message tag (message component + message id) should never change,
> > > > > if you change the code structure the module name might change as well.
> > > > 
> > > > Um, isn't that the point?  If the code structure changes, then perhaps
> > > > the message also should change?  If not, it's trival to adjust.
> > > 
> > > NO! The message nor the message tag should change if the message
> > > semantically still reports the same thing. If the meaning of the message
> > > changes then change the message AND the message tag.
> > 
> > Why can't the message reporting change?  What's the reluctance for
> > change here for something that did happen to move to a different file?
> > It shouldn't matter _at all_ as you are only looking at the
> > tags/messages for a specific kernel version to ensure they match up.
> > Any future kernel version might have different ones.
> >
> > It's not like once you write a message/tag it will stay that way fixed
> > for all time, that's just not going to fly with the way the Linux kernel
> > is developed.
> 
> The message tag should uniquely identify the message so that the
> translation projects have something to work with. If we keep changing
> the message tag with each kernel release that will create a huge effort
> to keep track of the messages.

But that's the point here.  The kernel does change a lot with each
release (you have seen the numbers, right?)  And if a change happens,
then the message also needs to change as something changed!  Why would
you think that these messages could be static till the end of time?
That's not how the kernel works.

> > > > > 2) we want to be able to use the same kmsg component in multiple .c
> > > > > files. 
> > > > 
> > > > Why would this matter?  It's just a "tag", who cares about the actual
> > > > name?
> > > 
> > > The actual name is not really important, but if the name is choosen
> > > wisely it does convey information. Guess what "dasd.17" tells you
> > > something about the dasd driver, "zfcp.42" about the zfcp driver and so
> > > on. The code structure should not dictate how the message tag is
> > > created.
> > 
> > The message tag should not dictate anything except how to look it up
> > somehow.  So it doesn't matter if the name changes, as long as the
> > ability to get the real information is still there.
> > 
> > So the kernel could change the tags every other release and there would
> > be no problem.
> 
> I think the unique message ids are very important. If we change them all
> the time this would severly limit the value of the kernel message
> catalog.

Again, they will be unique, but again, they will change as the kernel
changes, they will have to.

thanks,

greg k-h
--
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/