From: Martin Schwidefsky <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
---
Documentation/kmsg/s390/xpram | 54 ++++++++++++++++++++++++++++++++++++++++++
drivers/s390/block/xpram.c | 41 ++++++++++++++-----------------
2 files changed, 73 insertions(+), 22 deletions(-)
Index: linux-2.6/Documentation/kmsg/s390/xpram
===================================================================
--- /dev/null
+++ linux-2.6/Documentation/kmsg/s390/xpram
@@ -0,0 +1,54 @@
+/*?
+ * Tag: xpram.1
+ * Text: "%d is not a valid number of XPRAM devices"
+ * Severity: Error
+ * Parameter:
+ * @1: number of partitions
+ * Description:
+ * The number of XPRAM partitions specified for the 'devs' module parameter
+ * or with the 'xpram.parts' kernel parameter must be an integer in the
+ * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
+ * that are probably not configured as intended.
+ * User action:
+ * If the XPRAM device driver has been compiled as a separate module,
+ * unload the module and load it again with a correct value for the
+ * 'devs' module parameter. If the XPRAM device driver has been compiled
+ * into the kernel, correct the 'xpram.parts' parameter in the kernel
+ * parameter line and restart Linux.
+ */
+
+/*?
+ * Tag: xpram.2
+ * Text: "Not enough expanded memory available"
+ * Severity: Error
+ * Description:
+ * The amount of expanded memory required to set up your XPRAM partitions
+ * depends on the 'sizes' parameter specified for the xpram module or on
+ * the specifications for the 'xpram.parts' parameter if the XPRAM device
+ * driver has been compiled into the kernel. Your
+ * current specification exceed the amount of available expanded memory.
+ * Your XPRAM partitions are probably not configured as intended.
+ * User action:
+ * If the XPRAM device driver has been compiled as a separate module,
+ * unload the xpram module and load it again with an appropriate value
+ * for the 'sizes' module parameter. If the XPRAM device driver has been
+ * compiled into the kernel, adjust the 'xpram.parts' parameter in the
+ * kernel parameter line and restart Linux. If you need more than the
+ * available expanded memory, increase the expanded memory allocation for
+ * your virtual hardware or LPAR.
+ */
+
+/*?
+ * Tag: xpram.3
+ * Text: "No expanded memory available"
+ * Severity: Error
+ * Description:
+ * The XPRAM device driver has been loaded in a Linux instance that runs
+ * in an LPAR or virtual hardware without expanded memory.
+ * are created.
+ * User action:
+ * Allocate expanded memory for your LPAR or virtual hardware or do not
+ * load the xpram module. You can ignore this message, if you do not want
+ * to create XPRAM partitions.
+ */
+
Index: linux-2.6/drivers/s390/block/xpram.c
===================================================================
--- linux-2.6.orig/drivers/s390/block/xpram.c
+++ linux-2.6/drivers/s390/block/xpram.c
@@ -36,18 +36,15 @@
#include <linux/hdreg.h> /* HDIO_GETGEO */
#include <linux/sysdev.h>
#include <linux/bio.h>
+#include <linux/kmsg.h>
#include <asm/uaccess.h>
+#define KMSG_COMPONENT "xpram"
+
#define XPRAM_NAME "xpram"
#define XPRAM_DEVS 1 /* one partition */
#define XPRAM_MAX_DEVS 32 /* maximal number of devices (partitions) */
-#define PRINT_DEBUG(x...) printk(KERN_DEBUG XPRAM_NAME " debug:" x)
-#define PRINT_INFO(x...) printk(KERN_INFO XPRAM_NAME " info:" x)
-#define PRINT_WARN(x...) printk(KERN_WARNING XPRAM_NAME " warning:" x)
-#define PRINT_ERR(x...) printk(KERN_ERR XPRAM_NAME " error:" x)
-
-
typedef struct {
unsigned int size; /* size of xpram segment in pages */
unsigned int offset; /* start page of xpram segment */
@@ -263,7 +260,7 @@ static int __init xpram_setup_sizes(unsi
/* Check number of devices. */
if (devs <= 0 || devs > XPRAM_MAX_DEVS) {
- PRINT_ERR("invalid number %d of devices\n",devs);
+ kmsg_err(1, "%d is not a valid number of XPRAM devices\n",devs);
return -EINVAL;
}
xpram_devs = devs;
@@ -294,22 +291,22 @@ static int __init xpram_setup_sizes(unsi
mem_auto_no++;
}
- PRINT_INFO(" number of devices (partitions): %d \n", xpram_devs);
+ kmsg_info(0, " number of devices (partitions): %d \n", xpram_devs);
for (i = 0; i < xpram_devs; i++) {
if (xpram_sizes[i])
- PRINT_INFO(" size of partition %d: %u kB\n",
- i, xpram_sizes[i]);
+ kmsg_info(0, " size of partition %d: %u kB\n",
+ i, xpram_sizes[i]);
else
- PRINT_INFO(" size of partition %d to be set "
- "automatically\n",i);
+ kmsg_info(0, " size of partition %d to be set "
+ "automatically\n",i);
}
- PRINT_DEBUG(" memory needed (for sized partitions): %lu kB\n",
- mem_needed);
- PRINT_DEBUG(" partitions to be sized automatically: %d\n",
- mem_auto_no);
+ kmsg_info(0, " memory needed (for sized partitions): %lu kB\n",
+ mem_needed);
+ kmsg_info(0, " partitions to be sized automatically: %d\n",
+ mem_auto_no);
if (mem_needed > pages * 4) {
- PRINT_ERR("Not enough expanded memory available\n");
+ kmsg_err(2, "Not enough expanded memory available\n");
return -EINVAL;
}
@@ -321,8 +318,8 @@ static int __init xpram_setup_sizes(unsi
*/
if (mem_auto_no) {
mem_auto = ((pages - mem_needed / 4) / mem_auto_no) * 4;
- PRINT_INFO(" automatically determined "
- "partition size: %lu kB\n", mem_auto);
+ kmsg_info(0, " automatically determined "
+ "partition size: %lu kB\n", mem_auto);
for (i = 0; i < xpram_devs; i++)
if (xpram_sizes[i] == 0)
xpram_sizes[i] = mem_auto;
@@ -412,12 +409,12 @@ static int __init xpram_init(void)
/* Find out size of expanded memory. */
if (xpram_present() != 0) {
- PRINT_WARN("No expanded memory available\n");
+ kmsg_err(3, "No expanded memory available\n");
return -ENODEV;
}
xpram_pages = xpram_highest_page_index() + 1;
- PRINT_INFO(" %u pages expanded memory found (%lu KB).\n",
- xpram_pages, (unsigned long) xpram_pages*4);
+ kmsg_info(0, " %u pages expanded memory found (%lu KB).\n",
+ xpram_pages, (unsigned long) xpram_pages*4);
rc = xpram_setup_sizes(xpram_pages);
if (rc)
return rc;
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Wed, Jul 30, 2008 at 06:56:59PM +0200, Martin Schwidefsky wrote:
> From: Martin Schwidefsky <[email protected]>
>
> Signed-off-by: Martin Schwidefsky <[email protected]>
> ---
>
> Documentation/kmsg/s390/xpram | 54 ++++++++++++++++++++++++++++++++++++++++++
> drivers/s390/block/xpram.c | 41 ++++++++++++++-----------------
> 2 files changed, 73 insertions(+), 22 deletions(-)
>
> Index: linux-2.6/Documentation/kmsg/s390/xpram
> ===================================================================
> --- /dev/null
> +++ linux-2.6/Documentation/kmsg/s390/xpram
> @@ -0,0 +1,54 @@
> +/*?
> + * Tag: xpram.1
Ick, so you are going to have to define a message number per file?
How is that going to work, it looks like you use ids 0-2 below in the .c
file, yet in this documentation file they are 1-3. Off by one
somewhere? :)
> + * Text: "%d is not a valid number of XPRAM devices"
> + * Severity: Error
> + * Parameter:
> + * @1: number of partitions
> + * Description:
> + * The number of XPRAM partitions specified for the 'devs' module parameter
> + * or with the 'xpram.parts' kernel parameter must be an integer in the
> + * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
> + * that are probably not configured as intended.
> + * User action:
> + * If the XPRAM device driver has been compiled as a separate module,
> + * unload the module and load it again with a correct value for the
> + * 'devs' module parameter. If the XPRAM device driver has been compiled
> + * into the kernel, correct the 'xpram.parts' parameter in the kernel
> + * parameter line and restart Linux.
> + */
Any way to put this stuff in the .c file itself? It's hard enough
getting people to update Documentation/ABI/, knowing to go modify
something else in the Documentation directory is going to be _very_
difficult.
>
> +#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).
> /* Check number of devices. */
> if (devs <= 0 || devs > XPRAM_MAX_DEVS) {
> - PRINT_ERR("invalid number %d of devices\n",devs);
> + kmsg_err(1, "%d is not a valid number of XPRAM devices\n",devs);
> return -EINVAL;
Magic number "1" here? See comment above about this.
thanks,
greg k-h
On Wed, 2008-07-30 at 12:43 -0700, Greg KH wrote:
> On Wed, Jul 30, 2008 at 06:56:59PM +0200, Martin Schwidefsky wrote:
> > Index: linux-2.6/Documentation/kmsg/s390/xpram
> > ===================================================================
> > --- /dev/null
> > +++ linux-2.6/Documentation/kmsg/s390/xpram
> > @@ -0,0 +1,54 @@
> > +/*?
> > + * Tag: xpram.1
>
> Ick, so you are going to have to define a message number per file?
> How is that going to work, it looks like you use ids 0-2 below in the .c
> file, yet in this documentation file they are 1-3. Off by one
> somewhere? :)
The kmsg number 0 is special, the message tag will not include the
message number for id 0. And the script won't complain that the message
description is missing.
And yes, we WANT to define the message numbers per kmsg component.
> > + * Text: "%d is not a valid number of XPRAM devices"
> > + * Severity: Error
> > + * Parameter:
> > + * @1: number of partitions
> > + * Description:
> > + * The number of XPRAM partitions specified for the 'devs' module parameter
> > + * or with the 'xpram.parts' kernel parameter must be an integer in the
> > + * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
> > + * that are probably not configured as intended.
> > + * User action:
> > + * If the XPRAM device driver has been compiled as a separate module,
> > + * unload the module and load it again with a correct value for the
> > + * 'devs' module parameter. If the XPRAM device driver has been compiled
> > + * into the kernel, correct the 'xpram.parts' parameter in the kernel
> > + * parameter line and restart Linux.
> > + */
>
> Any way to put this stuff in the .c file itself? It's hard enough
> getting people to update Documentation/ABI/, knowing to go modify
> something else in the Documentation directory is going to be _very_
> difficult.
Yes, already implemented. Just put the comment anywhere in the .c file
where the message is printed. The Documentation/kmsg directory is just
an additional option.
>
> >
> > +#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.
2) we want to be able to use the same kmsg component in multiple .c
files.
> > /* Check number of devices. */
> > if (devs <= 0 || devs > XPRAM_MAX_DEVS) {
> > - PRINT_ERR("invalid number %d of devices\n",devs);
> > + kmsg_err(1, "%d is not a valid number of XPRAM devices\n",devs);
> > return -EINVAL;
>
> Magic number "1" here? See comment above about this.
This is just the kmsg printk for xpram.1, see comment above about id 0.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Hi!
> From: Martin Schwidefsky <[email protected]>
>
> Signed-off-by: Martin Schwidefsky <[email protected]>
> ---
>
> Documentation/kmsg/s390/xpram | 54 ++++++++++++++++++++++++++++++++++++++++++
> drivers/s390/block/xpram.c | 41 ++++++++++++++-----------------
> 2 files changed, 73 insertions(+), 22 deletions(-)
>
> Index: linux-2.6/Documentation/kmsg/s390/xpram
> ===================================================================
> --- /dev/null
> +++ linux-2.6/Documentation/kmsg/s390/xpram
> @@ -0,0 +1,54 @@
> +/*?
> + * Tag: xpram.1
> + * Text: "%d is not a valid number of XPRAM devices"
> + * Severity: Error
> + * Parameter:
> + * @1: number of partitions
> + * Description:
> + * The number of XPRAM partitions specified for the 'devs' module parameter
> + * or with the 'xpram.parts' kernel parameter must be an integer in the
> + * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
> + * that are probably not configured as intended.
> + * User action:
> + * If the XPRAM device driver has been compiled as a separate module,
> + * unload the module and load it again with a correct value for the
> + * 'devs' module parameter. If the XPRAM device driver has been compiled
> + * into the kernel, correct the 'xpram.parts' parameter in the kernel
> + * parameter line and restart Linux.
It is "Kernel command line". Plus, I do not think I find "User action"
section really helpful here.
...user that does not understand what "between 1 and 32 means" is
unlikely to know if the driver is built-in or module...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2008-08-04 at 08:48 +0200, Pavel Machek wrote:
> It is "Kernel command line". Plus, I do not think I find "User action"
> section really helpful here.
Ok, I'll fix that.
> ...user that does not understand what "between 1 and 32 means" is
> unlikely to know if the driver is built-in or module...
Yeah, it is a trivial example for a user action. Perhaps even too
trivial. On the other hand it doesn't hurt either. At least it is good
english thanks to our ID department.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Thu, Jul 31, 2008 at 10:33:42AM +0200, Martin Schwidefsky wrote:
> On Wed, 2008-07-30 at 12:43 -0700, Greg KH wrote:
> > On Wed, Jul 30, 2008 at 06:56:59PM +0200, Martin Schwidefsky wrote:
> > > Index: linux-2.6/Documentation/kmsg/s390/xpram
> > > ===================================================================
> > > --- /dev/null
> > > +++ linux-2.6/Documentation/kmsg/s390/xpram
> > > @@ -0,0 +1,54 @@
> > > +/*?
> > > + * Tag: xpram.1
> >
> > Ick, so you are going to have to define a message number per file?
> > How is that going to work, it looks like you use ids 0-2 below in the .c
> > file, yet in this documentation file they are 1-3. Off by one
> > somewhere? :)
>
> The kmsg number 0 is special, the message tag will not include the
> message number for id 0. And the script won't complain that the message
> description is missing.
Was "0 is special" defined anywhere that I missed?
> And yes, we WANT to define the message numbers per kmsg component.
But again, you have to manually match up numbers by hand, that's prone
to get messy very quickly.
> > > + * Text: "%d is not a valid number of XPRAM devices"
> > > + * Severity: Error
> > > + * Parameter:
> > > + * @1: number of partitions
> > > + * Description:
> > > + * The number of XPRAM partitions specified for the 'devs' module parameter
> > > + * or with the 'xpram.parts' kernel parameter must be an integer in the
> > > + * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
> > > + * that are probably not configured as intended.
> > > + * User action:
> > > + * If the XPRAM device driver has been compiled as a separate module,
> > > + * unload the module and load it again with a correct value for the
> > > + * 'devs' module parameter. If the XPRAM device driver has been compiled
> > > + * into the kernel, correct the 'xpram.parts' parameter in the kernel
> > > + * parameter line and restart Linux.
> > > + */
> >
> > Any way to put this stuff in the .c file itself? It's hard enough
> > getting people to update Documentation/ABI/, knowing to go modify
> > something else in the Documentation directory is going to be _very_
> > difficult.
>
> Yes, already implemented. Just put the comment anywhere in the .c file
> where the message is printed. The Documentation/kmsg directory is just
> an additional option.
Why not have your example show this?
> > > +#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.
> 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?
thanks,
greg k-h
On Tue, 2008-08-05 at 15:34 -0700, Greg KH wrote:
> On Thu, Jul 31, 2008 at 10:33:42AM +0200, Martin Schwidefsky wrote:
> > On Wed, 2008-07-30 at 12:43 -0700, Greg KH wrote:
> > > On Wed, Jul 30, 2008 at 06:56:59PM +0200, Martin Schwidefsky wrote:
> > > > Index: linux-2.6/Documentation/kmsg/s390/xpram
> > > > ===================================================================
> > > > --- /dev/null
> > > > +++ linux-2.6/Documentation/kmsg/s390/xpram
> > > > @@ -0,0 +1,54 @@
> > > > +/*?
> > > > + * Tag: xpram.1
> > >
> > > Ick, so you are going to have to define a message number per file?
> > > How is that going to work, it looks like you use ids 0-2 below in the .c
> > > file, yet in this documentation file they are 1-3. Off by one
> > > somewhere? :)
> >
> > The kmsg number 0 is special, the message tag will not include the
> > message number for id 0. And the script won't complain that the message
> > description is missing.
>
> Was "0 is special" defined anywhere that I missed?
>From the patch description of the kernel message catalog script:
The kmsg check is invoked with "make D=1" and reads the source files for
all objects that are built by the current configuration and searches for
matching kmsg descriptions for the kmsg messages in the source which
have a messages id > 0. If a message description can not be found the
script prints a blueprint and causes a make error.
> > And yes, we WANT to define the message numbers per kmsg component.
>
> But again, you have to manually match up numbers by hand, that's prone
> to get messy very quickly.
The kmsg catalog script if called with "make D=1" will check all the
messages in the current build. When a message is introduced you have to
pick a free number. The checking is done automatically and errors will
be caught without trouble.
> > > > + * Text: "%d is not a valid number of XPRAM devices"
> > > > + * Severity: Error
> > > > + * Parameter:
> > > > + * @1: number of partitions
> > > > + * Description:
> > > > + * The number of XPRAM partitions specified for the 'devs' module parameter
> > > > + * or with the 'xpram.parts' kernel parameter must be an integer in the
> > > > + * range 1 to 32. The XPRAM device driver created a maximum of 32 partitions
> > > > + * that are probably not configured as intended.
> > > > + * User action:
> > > > + * If the XPRAM device driver has been compiled as a separate module,
> > > > + * unload the module and load it again with a correct value for the
> > > > + * 'devs' module parameter. If the XPRAM device driver has been compiled
> > > > + * into the kernel, correct the 'xpram.parts' parameter in the kernel
> > > > + * parameter line and restart Linux.
> > > > + */
> > >
> > > Any way to put this stuff in the .c file itself? It's hard enough
> > > getting people to update Documentation/ABI/, knowing to go modify
> > > something else in the Documentation directory is going to be _very_
> > > difficult.
> >
> > Yes, already implemented. Just put the comment anywhere in the .c file
> > where the message is printed. The Documentation/kmsg directory is just
> > an additional option.
>
> Why not have your example show this?
Ok, fair enough.
> > > > +#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.
> > 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.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
On Wed, Aug 06, 2008 at 10:46:13AM +0200, Martin Schwidefsky wrote:
> On Tue, 2008-08-05 at 15:34 -0700, Greg KH wrote:
> > On Thu, Jul 31, 2008 at 10:33:42AM +0200, Martin Schwidefsky wrote:
> > > On Wed, 2008-07-30 at 12:43 -0700, Greg KH wrote:
> > > > On Wed, Jul 30, 2008 at 06:56:59PM +0200, Martin Schwidefsky wrote:
> > > > > Index: linux-2.6/Documentation/kmsg/s390/xpram
> > > > > ===================================================================
> > > > > --- /dev/null
> > > > > +++ linux-2.6/Documentation/kmsg/s390/xpram
> > > > > @@ -0,0 +1,54 @@
> > > > > +/*?
> > > > > + * Tag: xpram.1
> > > >
> > > > Ick, so you are going to have to define a message number per file?
> > > > How is that going to work, it looks like you use ids 0-2 below in the .c
> > > > file, yet in this documentation file they are 1-3. Off by one
> > > > somewhere? :)
> > >
> > > The kmsg number 0 is special, the message tag will not include the
> > > message number for id 0. And the script won't complain that the message
> > > description is missing.
> >
> > Was "0 is special" defined anywhere that I missed?
>
> >From the patch description of the kernel message catalog script:
>
> The kmsg check is invoked with "make D=1" and reads the source files for
> all objects that are built by the current configuration and searches for
> matching kmsg descriptions for the kmsg messages in the source which
> have a messages id > 0. If a message description can not be found the
> script prints a blueprint and causes a make error.
Ok, but you don't describe messages with "0" in them :)
> > > > > +#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.
> > > 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.
thanks,
greg k-h
On Wed, 2008-08-06 at 13:11 -0700, Greg KH wrote:
> > >From the patch description of the kernel message catalog script:
> >
> > The kmsg check is invoked with "make D=1" and reads the source files for
> > all objects that are built by the current configuration and searches for
> > matching kmsg descriptions for the kmsg messages in the source which
> > have a messages id > 0. If a message description can not be found the
> > script prints a blueprint and causes a make error.
>
> Ok, but you don't describe messages with "0" in them :)
I'll add the creation of a howto to my to-do list that describes how to
work with kmsg.
> > > > > > +#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.
> > > > 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.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
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