Re: README 1ST - New problem logging macros (2.5.38)

[Andrey Savochkin]

My $0.02.

I understand some of the reasons why certain logging standardization
is helpful.

An example: an administrator is mainly interested in problems with the disks.
Can anyone write, say, a regular expression matching printk messages related
to disks with very low false positive and false negative levels?
I can't.

The current Larry's proposal has a disadvantage of being so big.
Anyone will have a strong internal opposition to the need to learn this
interface for just a simple logging.

Second.  One of the most important things is handling of log messages
split over multiple printk and, possibly, multiple lines.
Larry seemed to omit the most interesting place in eepro100 driver:
speedo_show_state()  :-)

Any logging infrastructure not being able to deal with places like
speedo_show_state() is only half-useful, unfortunately.
The user-level log management system should be notified that
such a dump is just a single (long) piece of information, consisting of
multiple lines.

I would think about an interface looking like:
	log_piece_start_netdev(dev);
        printk(KERN_WARNING "%s: Transmit timed out: status %4.4x "
                  " %4.4x at %d/%d command %8.8x.\n",
                   dev->name, status, inw(ioaddr + SCBCmd),
                   sp->dirty_tx, sp->cur_tx,
                   sp->tx_ring[sp->dirty_tx % TX_RING_SIZE].status);
        speedo_show_state(dev);
	log_piece_end_netdev(dev);
It is simple and not intrusive, allowing to keep most of the code as it is
(or as driver author prefers).

On top of that simple interface, you can have whatever complex infrastructure
you want, gradually bringing the code to something like
	log_piece_start_netdev(dev);
	log_severity(LOG_WARNING);
	log_netdev_attrib(LOG_NETDEV_TRANSMIT);
        printk(KERN_WARNING "%s: Transmit timed out: status %4.4x "
                  " %4.4x at %d/%d command %8.8x.\n",
                   dev->name, status, inw(ioaddr + SCBCmd),
                   sp->dirty_tx, sp->cur_tx,
                   sp->tx_ring[sp->dirty_tx % TX_RING_SIZE].status);
	log_severity(LOG_DEBUG);
        speedo_show_state(dev);
	log_piece_end_netdev(dev);
or whatever you consider nice and useful.

Best regards
		Andrey

P.S. of course, wait_for_cmd_done should have net_device as an argument,
and any logging infrastructure can't help there :-)