Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)

[Jeff Garzik <jgarzik@pobox.com>]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38) --]
[-- Type: message/rfc822, Size: 2999 bytes --]

From: Jeff Garzik <jgarzik@pobox.com>
To: Larry Kessler <kessler@us.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,  Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@us.ibm.com,  mailing@us.ibm.com,  list@us.ibm.com
Subject: Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)
Date: Tue, 24 Sep 2002 00:55:28 -0400
Message-ID: <3D8FF040.2040905@pobox.com>

Larry Kessler wrote:
> Jeff Garzik wrote:
> 
>>>      }
>>>      if (!request_mem_region(pci_resource_start(pdev, 0),
>>>                      pci_resource_len(pdev, 0), "eepro100")) {
>>>-             printk (KERN_ERR "eepro100: cannot reserve MMIO region\n");
>>>+             pci_problem(LOG_ERR, pdev, "eepro100: cannot reserve MMIO region");
>>
>>bloat, no advantage over printk
> 
> 
> the advantage is that the string, which means plenty to the developer, but possibly
> much less to a Sys Admin, can be replaced with a more descriptive message,
> in the local language, by editing the formatting template in user-space.

So, a static string passed to printk can't be translated, but a static 
string passed to pci_problem() can?

And in your view is it impossible to deduce a format string from the 
current code?


> 
> 
>>>              if (sum != 0xBABA)
>>>-                     printk(KERN_WARNING "%s: Invalid EEPROM checksum %#4.4x, "
>>>-                                "check settings before activating this device!\n",
>>>-                                dev->name, sum);
>>>+                     net_pci_problem(LOG_WARNING, dev, pdev, "Invalid EEPROM checksum, "
>>>+                                "check settings before activating this device!",
>>
>>>+                                detail(checksum, "%#4.4x", sum));
>>
>>bloat, checksum is purely informational, and can be obtained through
>>other means
> 
> 
> indeed.  See previous comment.


indeed :)

And for thinking outside the box, here's a random idea:  when 
CONFIG_EVLOG is defined, printk() turns into a tagged format that spits 
out its format string, then a list of variable names and values.  Given 
some C and cpp magic, that should be possible with no code changes at 
all to drivers.

An overriding objection to all this need of information.  It is so wrong 
to decide to just continuing dump all information available, and hope 
that it will become useful.  Decide which information is useful first...

Do you guys even have an idea what diagnostic info is useful from 
network drivers?  from SCSI drivers?  If yes, speak up.  I would love to 
improve the diagnostics of my net drivers where possible.  If not... 
please figure out the problem before implementing a solution.

	Jeff