All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peschke <mp3@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Christof Schmitt <christof.schmitt@de.ibm.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-scsi@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [patch 08/11] zfcp: Add traces for state changes.
Date: Thu, 27 Mar 2008 15:31:55 +0100	[thread overview]
Message-ID: <47EBAFDB.8040101@de.ibm.com> (raw)
In-Reply-To: <20080327142001.GA4122@osiris.boeblingen.de.ibm.com>

Heiko Carstens schrieb:
>> -	zfcp_erp_modify_adapter_status(adapter,
>> +	zfcp_erp_modify_adapter_status(adapter, 24, 0,
>>  				       ZFCP_STATUS_COMMON_OPEN, ZFCP_CLEAR);
>>  }
>>
>> @@ -216,7 +216,7 @@ zfcp_erp_adapter_reopen_internal(struct 
>>  			       zfcp_get_busid_by_adapter(adapter));
>>  		debug_text_event(adapter->erp_dbf, 5, "a_ro_f");
>>  		/* ensure propagation of failed status to new devices */
>> -		zfcp_erp_adapter_failed(adapter);
>> +		zfcp_erp_adapter_failed(adapter, 13, 0);
> 
> 24, 13? I bet you made sure that these numbers fit the huge list.. and
> hopefully nobody will ever add anything in between.
> Why not just pass a string? This looks way too complicated and error-prone.

Well, do you remember the scheme introduced by our (s390) kernel message 
catalog? Same approach.

I think numbers are superior. I won't store strings because I want to 
keep trace entries as small as possible - 1 or 2 bytes for a number vs. 
lots of bytes for a string ... for each event.

Yes, I did this carefully. The strings array helps to keep track of used 
IDs.

Regards,
Martin

  reply	other threads:[~2008-03-27 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 13:21 [patch 00/11] zfcp debug trace update Christof Schmitt
2008-03-27 13:21 ` [patch 01/11] zfcp: Introduce a helper function that dumps hex data to a zfcp trace Christof Schmitt
2008-03-27 13:21 ` [patch 02/11] zfcp: Clean up _zfcp_san_dbf_event_common_els Christof Schmitt
2008-03-27 13:21 ` [patch 03/11] zfcp: Remove qtcb dump to kernel log Christof Schmitt
2008-03-27 13:21 ` [patch 04/11] zfcp: Add qtcb dump to hba debug trace Christof Schmitt
2008-03-27 13:21 ` [patch 05/11] zfcp: Introduce printf helper functions for " Christof Schmitt
2008-03-27 13:22 ` [patch 06/11] zfcp: Register new recovery trace Christof Schmitt
2008-03-27 13:22 ` [patch 07/11] zfcp: Add trace records for recovery thread and its queues Christof Schmitt
2008-03-27 13:22 ` [patch 08/11] zfcp: Add traces for state changes Christof Schmitt
2008-03-27 14:20   ` Heiko Carstens
2008-03-27 14:31     ` Martin Peschke [this message]
2008-03-27 13:22 ` [patch 09/11] zfcp: Trace all triggers of error recovery activity Christof Schmitt
2008-03-27 13:22 ` [patch 10/11] zfcp: Add trace records for recovery actions Christof Schmitt
2008-03-27 13:22 ` [patch 11/11] zfcp: Remove obsolete erp_dbf trace Christof Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47EBAFDB.8040101@de.ibm.com \
    --to=mp3@de.ibm.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=christof.schmitt@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.