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

[Jeff Garzik <jgarzik@pobox.com>]

Rusty Russell wrote:
> In message <3D8FD0A9.1010906@pobox.com> you write:
> 
>>>@@ -325,7 +326,8 @@
>>> 	while(inb(cmd_ioaddr) && --wait >= 0);
>>> #ifndef final_version
>>> 	if (wait < 0)
>>>-		printk(KERN_ALERT "eepro100: wait_for_cmd_done timeout!\n");
>>>+		problem(LOG_ALERT, "eepro100: wait_for_cmd_done timeout!",
>>>+				detail(ioaddr, "%lx", cmd_ioaddr));
>>
>>bloat, the ioaddr can easily be deduced
> 
> 
> No!  That's *exactly* the problem: you see:
> 	eepro100: wait_for_cmd_done timeout!
> 
> in your logs, now *which* of the 5 eepro100 cards was it?
> 
> wait_for_cmd_done(long cmd_ioaddr) should take a 'struct net_device *'
> and use net_problem, then no details needed.

right, that's a bug, it needs struct net_device * like the standard 
Becker style.


>>>-		printk (KERN_ERR "eepro100: cannot reserve MMIO region\n");
>>>+		pci_problem(LOG_ERR, pdev, "eepro100: cannot reserve MMIO regio
>>
> n");
> 
>>bloat, no advantage over printk
> 
> 
> Now, which of those 5 cards was it again?

Another bug, this driver should be using pci_request_regions() which 
prints that stuff out :)

Does IBM want to submit a patch that cleans up these problems, and makes 
the existing event logging more standard [and is compatible with 
existing 2.4 and 2.5 kernels]?

As an aside, changing all those printks also introduces a _huge_ PITA 
for driver developers porting drivers back and forth between 2.4 and 2.5.

	Jeff