Another libata TODO item

Another libata TODO item

[Jeff Garzik]

Difficulty:  beginner / intermediate

Modern network drivers have a per-NIC list of debugging messages that 
can be enabled/disabled at runtime, implemented as a bitmask named 
'msg_enable' in each driver.  VERY useful for tracing specific events 
during debugging.  grep for 'msg_enable', 'netif_msg_', and 'NETIF_MSG_'.

To make libata debugging easier and more fine-grained, we should convert 
DPRINTK/VPRINTK calls in libata to code that looks like

	if (ata_msg_xxx(ap->msg_enable))
		printk(...)

The task involves:

* reviewing net driver msg_enable usage
* reviewing original netif_msg documentation by Donald Becker, at 
(scroll down)
http://www.scyld.com/pipermail/vortex/2001-November/001426.html

* designing a sliding scale of ever-more-verbose classes of messages, 
for libata and libata drivers
* design a method by which userspace may change the per-port msg_enable 
variable in libata

* implement the sliding scale as ATA_MSG_xxx / ata_msg_xxx()
* add msg_enable to struct ata_port
* implement method of setting ap->msg_enable via userspace
* convert messages in libata-core/libata-scsi
* convert messages in each driver
* add 'debug' module option to each driver, in a manner that duplicates 
net driver module options
* test!

Re: Another libata TODO item

[Christoph Hellwig]

On Wed, Aug 24, 2005 at 02:17:11AM -0400, Jeff Garzik wrote:
> 
> Difficulty:  beginner / intermediate
> 
> Modern network drivers have a per-NIC list of debugging messages that 
> can be enabled/disabled at runtime, implemented as a bitmask named 
> 'msg_enable' in each driver.  VERY useful for tracing specific events 
> during debugging.  grep for 'msg_enable', 'netif_msg_', and 'NETIF_MSG_'.
> 
> To make libata debugging easier and more fine-grained, we should convert 
> DPRINTK/VPRINTK calls in libata to code that looks like
> 
> 	if (ata_msg_xxx(ap->msg_enable))
> 		printk(...)

Would be nice if you could move that one up to the scsi layer and combine
it with the existing scsi core loglevel handling.

Re: Another libata TODO item

[Jeff Garzik]

Christoph Hellwig wrote:
> On Wed, Aug 24, 2005 at 02:17:11AM -0400, Jeff Garzik wrote:
>>To make libata debugging easier and more fine-grained, we should convert 
>>DPRINTK/VPRINTK calls in libata to code that looks like
>>
>>	if (ata_msg_xxx(ap->msg_enable))
>>		printk(...)
> 
> 
> Would be nice if you could move that one up to the scsi layer and combine
> it with the existing scsi core loglevel handling.


Doubtful.  libata's use of SCSI will become optional, so using SCSI 
logging throughout libata core would be inappropriate.  Block layer 
would be more reasonable.

In any case, I also contine to be skeptical of in-kernel logging subsystems.

	Jeff

Re: Another libata TODO item

[Roland Dreier]

    Jeff> In any case, I also contine to be skeptical of in-kernel
    Jeff> logging subsystems.

Aren't you proposing a libata logging subsystem?

 - R.

Re: Another libata TODO item

[Jeff Garzik]

Roland Dreier wrote:
>     Jeff> In any case, I also contine to be skeptical of in-kernel
>     Jeff> logging subsystems.
> 
> Aren't you proposing a libata logging subsystem?

Look at net drivers.  Theres no real infrastructure beyond bit tests and 
printks.  I wouldn't call that a subsystem, so, I wouldn't call this one 
such either.

	Jeff

Re: Another libata TODO item

[Roland Dreier]

    Jeff> Look at net drivers.  Theres no real infrastructure beyond
    Jeff> bit tests and printks.  I wouldn't call that a subsystem,
    Jeff> so, I wouldn't call this one such either.

Well, scsi_logging.h isn't much of a subsystem either.

 - R.

Re: Another libata TODO item

[Jeff Garzik]

Roland Dreier wrote:
>     Jeff> Look at net drivers.  Theres no real infrastructure beyond
>     Jeff> bit tests and printks.  I wouldn't call that a subsystem,
>     Jeff> so, I wouldn't call this one such either.
> 
> Well, scsi_logging.h isn't much of a subsystem either.

You obviously did not grep for CONFIG_SCSI_LOGGING :)

	Jeff