Messages in this thread | | | Date | Thu, 20 Jun 2002 18:41:21 +0200 | From | Martin Dalecki <> | Subject | Re: [PATCH 2.5.22] simple ide-tape.c and ide-floppy.c cleanup |
| |
Użytkownik Bartlomiej Zolnierkiewicz napisał: > On Thu, 20 Jun 2002, Martin Dalecki wrote: > > >>Użytkownik Jens Axboe napisał: >> >>>On Thu, Jun 20 2002, Martin Dalecki wrote: >>> >>> >>>>U?ytkownik Jens Axboe napisa?: >>>> >>>> >>>>>On Wed, Jun 19 2002, Bartlomiej Zolnierkiewicz wrote: >>>>> >>>>>Looks pretty good in general, just one minor detail: >>>>> >>>>> >>>>> >>>>> >>>>>>+ >>>>>>+/* >>>>>>+ * ATAPI packet commands. >>>>>>+ */ >>>>>>+#define ATAPI_FORMAT_UNIT_CMD 0x04 >>>>>>+#define ATAPI_INQUIRY_CMD 0x12 >>>>> >>>>> >>>>>[snip] >>>>> >>>>>We already have the "full" list in cdrom.h (GPCMD_*), so lets just use >>>>>that. After all, ATAPI_MODE_SELECT10_CMD _is_ the same as the SCSI >>>>>variant (and I think the _CMD post fixing is silly, anyone familiar with >>>>>this is going to know what ATAPI_WRITE10 means just fine) >>>>> >>>>>Same for request_sense, that is already generalized in cdrom.h as well. >>>> >>>>I wonder what FreeBSD is using here? I see no need for invention at >>>>this place. >>> >>> >>>The invention would be adding the ATAPI_* commands, Linux has used the >>>GPCMD_ convention for quite some time now. >> >>Agreed. The ATAPI prefix would be confusing, since those are in reality SCSI >>commands anyway... > > > I think we should use scsi.h and get rid of GPCMD_* convention also. > Jens, do you want "corrected" patch?
Yes that would be best / modulo possible name space clashes. The names in scsi/scsi.h look too generic sometimes. Like:
#define TYPE_DISK 0x00 #define TYPE_TAPE 0x01 #define TYPE_PRINTER 0x02 #define TYPE_PROCESSOR 0x03 /* HP scanners use this */ #define TYPE_WORM 0x04 /* Treated as ROM by our system */ #define TYPE_ROM 0x05
or
/* * Status codes */
#define GOOD 0x00 #define BUSY 0x04
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |