Skip to contentSkip to conversation

ABORT_TASK defined in aic94xx_sas.h

PATCH Boaz Harrosh 3 participants 5 messages Feb 6, 2008 SCSI

lore
Share & tools
lore

Boaz Harrosh

author
#0 lore raw

include/scsi/scsi.h as a definition:
#define ABORT_TASK 0x0d

on the other hand drivers/scsi/aic94xx/aic94xx_sas.h has:
#define ABORT_TASK 0x03

am I right in thinking that aic94xx_sas.h is wrong in polluting the global name-space?

If you ask me aic94xx_sas.h is a global name-space minefield

(This gives me problems when trying to pull in scsi_eh.h into aic94xx source files)

perhaps:
---
From: Boaz Harrosh <[email protected]>
Date: Wed, 6 Feb 2008 15:35:37 +0200
Subject: [PATCH] aic94xx_sas: avoid conflict with scsi.h

drivers/scsi/aic94xx/aic94xx_sas.h would redefine ABORT_TASK as a different value.

Signed-off-by Boaz Harrosh <[email protected]>
---
 drivers/scsi/aic94xx/aic94xx_sas.h |    2 +-
 drivers/scsi/aic94xx/aic94xx_tmf.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/aic94xx/aic94xx_sas.h +1 -1
index fa7c529..912e6b7 100644
@@ -292,7 +292,7 @@ struct scb_header {
 #define INITIATE_SSP_TASK       0x00
 #define INITIATE_LONG_SSP_TASK  0x01
 #define INITIATE_BIDIR_SSP_TASK 0x02
-#define ABORT_TASK              0x03
+#define SCB_ABORT_TASK          0x03
 #define INITIATE_SSP_TMF        0x04
 #define SSP_TARG_GET_DATA       0x05
 #define SSP_TARG_GET_DATA_GOOD  0x06
drivers/scsi/aic94xx/aic94xx_tmf.c +1 -1
index 87b2f6e..b52124f 100644
@@ -369,7 +369,7 @@ int asd_abort_task(struct sas_task *task)
 		return -ENOMEM;
 	scb = ascb->scb;
 
-	scb->header.opcode = ABORT_TASK;
+	scb->header.opcode = SCB_ABORT_TASK;
 
 	switch (task->task_proto) {
 	case SAS_PROTOCOL_SATA:
Signature · 1 line
1.5.3.3
maintainer
#1 lore raw
Quoted 6 lines · Boaz Harrosh

include/scsi/scsi.h as a definition:
#define ABORT_TASK 0x0d

on the other hand drivers/scsi/aic94xx/aic94xx_sas.h has:
#define ABORT_TASK 0x03

Quoted 7 lines

am I right in thinking that aic94xx_sas.h is wrong in polluting the global name-space?

If you ask me aic94xx_sas.h is a global name-space minefield

(This gives me problems when trying to pull in scsi_eh.h into aic94xx source files)

Well, no, not in those terms. The global namespace exists in shared headers which it's a little hard to argue that aic94xx_sas.h is, being unusable by anything other than a single driver.

It is correct to say that include/scsi/scsi.h is polluting the global namespace, because that is pulled into a large section of the kernel.

The message code #defines in scsi.h are a horrible mess of SPI message defines and task management function defines each of which should arguably have a SPI_ and TMF_ global namespace discriminator (and the SPI_ ones be shovelled off into the SPI transport class header).

However, this looks like a reasonable hack.

James

author
#2 lore raw
Quoted 22 lines · James Bottomley
Quoted 6 lines · Boaz Harrosh

include/scsi/scsi.h as a definition:
#define ABORT_TASK 0x0d

on the other hand drivers/scsi/aic94xx/aic94xx_sas.h has:
#define ABORT_TASK 0x03

Quoted 7 lines

am I right in thinking that aic94xx_sas.h is wrong in polluting the global name-space?

If you ask me aic94xx_sas.h is a global name-space minefield

(This gives me problems when trying to pull in scsi_eh.h into aic94xx source files)

Well, no, not in those terms. The global namespace exists in shared headers which it's a little hard to argue that aic94xx_sas.h is, being unusable by anything other than a single driver.

It is correct to say that include/scsi/scsi.h is polluting the global namespace, because that is pulled into a large section of the kernel.

Quoted 10 lines

The message code #defines in scsi.h are a horrible mess of SPI message defines and task management function defines each of which should arguably have a SPI_ and TMF_ global namespace discriminator (and the SPI_ ones be shovelled off into the SPI transport class header).

However, this looks like a reasonable hack.

James

Point taken, you are right.

Please see that you approve of the name I gave it, I just got it from the nearest comment so I'm not even sure if it's related.

Thanks
Boaz

maintainer
#3 lore raw
Quoted 30 lines · Boaz Harrosh
Quoted 29 lines · James Bottomley
Quoted 6 lines · Boaz Harrosh

include/scsi/scsi.h as a definition:
#define ABORT_TASK 0x0d

on the other hand drivers/scsi/aic94xx/aic94xx_sas.h has:
#define ABORT_TASK 0x03

Quoted 7 lines

am I right in thinking that aic94xx_sas.h is wrong in polluting the global name-space?

If you ask me aic94xx_sas.h is a global name-space minefield

(This gives me problems when trying to pull in scsi_eh.h into aic94xx source files)

Well, no, not in those terms. The global namespace exists in shared headers which it's a little hard to argue that aic94xx_sas.h is, being unusable by anything other than a single driver.

It is correct to say that include/scsi/scsi.h is polluting the global namespace, because that is pulled into a large section of the kernel.

The message code #defines in scsi.h are a horrible mess of SPI message defines and task management function defines each of which should arguably have a SPI_ and TMF_ global namespace discriminator (and the SPI_ ones be shovelled off into the SPI transport class header).

However, this looks like a reasonable hack.

Quoted 8 lines
Quoted 3 lines

James

Point taken, you are right.

Please see that you approve of the name I gave it, I just got it from the nearest comment so I'm not even sure if it's related.

Yes, it's a sequencer control block opcode, so prefixing it with SCB_ is reasonable.

James

Acked-by
#4 lore raw
In reply to Boaz Harrosh
Quoted 11 lines · Boaz Harrosh

include/scsi/scsi.h as a definition:
#define ABORT_TASK 0x0d

on the other hand drivers/scsi/aic94xx/aic94xx_sas.h has:
#define ABORT_TASK 0x03

am I right in thinking that aic94xx_sas.h is wrong in polluting the global name-space?

If you ask me aic94xx_sas.h is a global name-space minefield

LOL, "global name-space minefield" -- that's funny.

Yeah, I didn't think the aic94xx_sas.h would be used the way it is (or that the SAS Stack would become a "pimple" as opposed to a layer as originally defined).

In macro name definitions, I tried to stay as close as possible to the specs of the chip.

Anyway, I ack this patch. See below.

(Maybe scsi.h::ABORT_TASK should go away for the better defined scsi.h::TMF_ABORT_TASK.)

Quoted 11 lines

(This gives me problems when trying to pull in scsi_eh.h into
aic94xx source files)

perhaps:
---
From: Boaz Harrosh <[email protected]>
Date: Wed, 6 Feb 2008 15:35:37 +0200
Subject: [PATCH] aic94xx_sas: avoid conflict with scsi.h

Quoted 5 lines

drivers/scsi/aic94xx/aic94xx_sas.h would redefine
ABORT_TASK
as a different value.

Signed-off-by Boaz Harrosh <[email protected]>
Acked-by Luben Tuikov <[email protected]>

Luben

Quoted 43 lines
---
 drivers/scsi/aic94xx/aic94xx_sas.h |    2 +-
 drivers/scsi/aic94xx/aic94xx_tmf.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/aic94xx/aic94xx_sas.h +1 -1
index fa7c529..912e6b7 100644
@@ -292,7 +292,7 @@ struct scb_header {
 #define INITIATE_SSP_TASK       0x00
 #define INITIATE_LONG_SSP_TASK  0x01
 #define INITIATE_BIDIR_SSP_TASK 0x02
-#define ABORT_TASK              0x03
+#define SCB_ABORT_TASK          0x03
 #define INITIATE_SSP_TMF        0x04
 #define SSP_TARG_GET_DATA       0x05
 #define SSP_TARG_GET_DATA_GOOD  0x06
drivers/scsi/aic94xx/aic94xx_tmf.c +1 -1
index 87b2f6e..b52124f 100644
@@ -369,7 +369,7 @@ int asd_abort_task(struct sas_task
 *task)
 		return -ENOMEM;
 	scb = ascb->scb;
 
-	scb->header.opcode = ABORT_TASK;
+	scb->header.opcode = SCB_ABORT_TASK;
 
 	switch (task->task_proto) {

case SAS_PROTOCOL_SATA:

Signature · 8 lines
1.5.3.3

-
To unsubscribe from this list: send the line
"unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at 
http://vger.kernel.org/majordomo-info.html