public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: "Wu, Gilbert" <Gilbert_Wu@adaptec.com>
Cc: Linux-scsi@vger.kernel.org
Subject: Re: [PATCH] aic94xx: fix smartctl utility problem
Date: Fri, 07 Sep 2007 19:00:40 -0400	[thread overview]
Message-ID: <46E1D818.4080608@garzik.org> (raw)
In-Reply-To: <BC382691D59EC94C8E57543C47EF8ED55B20C0@aime2k302.adaptec.com>

Wu, Gilbert wrote:
> HI Jeff,
> 
>   I was thinking the checking "READ/WRITE" command table is larger than
> my current table. This does not cover vendor-specific command. 

You can implement the check in a _far_ more optimal manner:

Possibility 1:

	static const u8 ata_rw_command_table[256] = {
		[ATA_CMD_READ]		= 1,
		[ATA_CMD_READ_EXT]	= 1,
		... other READ/WRITE commands here, always value==1 ...
	};

	...

	u8 ata_command = ... ;

	if (ata_rw_command_table[ata_command]) {
		/* it is a read/write command */
	} else {
		/* it is NOT a read/write command */
	}

Possibility 2:

	static inline int is_ata_rw_cmd(u8 ata_cmd)
	{
		switch (ata_cmd) {
		case ATA_CMD_READ:
		case ATA_CMD_READ_EXT:
		... other READ/WRITE commands here ...
			return 1;
		}

		return 0;
	}

Either way you avoid the iteration, and simplify things down to a single 
test.

Once that is done, it should be self-evident that testing -any- list of 
commands is O(1), rather than O(n) for the case of table iteration.  And 
therefore, the cost of checking "is it a READ/WRITE command?" is equal 
to the cost of checking for any other commands.


> Do you wan me just check READ/WRITE command? 

Yes, please.


> The aic94xx default implementation is all ATA command will be returning
> ATA output register if the command did not succeed.

Great!

	Jeff




  reply	other threads:[~2007-09-07 23:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-05 22:25 [PATCH] aic94xx: fix smartctl utility problem Gilbert Wu
2007-09-06 10:06 ` Jeff Garzik
2007-09-06 18:33   ` Wu, Gilbert
2007-09-07 23:00     ` Jeff Garzik [this message]
2007-09-07 23:58       ` Wu, Gilbert
  -- strict thread matches above, loose matches on Subject: below --
2007-09-14 12:30 Gilbert Wu
2007-09-14 17:26 ` Jeff Garzik
2007-09-14 17:30   ` Wu, Gilbert
2007-09-14 17:58 Gilbert Wu
2007-09-14 18:14 ` Jeff Garzik
2007-09-15 17:05 ` James Bottomley
2007-09-16 16:37   ` James Bottomley
2007-09-16 19:43     ` Jeff Garzik
2007-09-16 23:01     ` Douglas Gilbert
2007-09-16 23:21       ` James Bottomley
2007-09-17 20:53         ` Wu, Gilbert
2007-09-17 22:59           ` James Bottomley
2007-09-18  1:43             ` Wu, Gilbert
2007-09-18  3:31               ` James Bottomley
2007-09-21 18:53             ` Wu, Gilbert
2007-09-21 20:40               ` James Bottomley
2007-09-21 23:05                 ` Wu, Gilbert
2007-09-20 18:52         ` Douglas Gilbert
2007-09-18 20:35 ` Luben Tuikov

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=46E1D818.4080608@garzik.org \
    --to=jeff@garzik.org \
    --cc=Gilbert_Wu@adaptec.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox