Re: [RFC PATCH] HP (Compaq) Smart Array 5xxx controller SCSI driver
From: Hannes Reinecke
Date: Tue Jul 22 2008 - 03:02:59 EST
FUJITA Tomonori wrote:
This is a SCSI driver for HP (Compaq) Smart Array 5xxx controllers.YES! Finally!
SCSI people can skip the following two paragraphs.Yes.
Currently, a driver for HP (Compaq) Smart Array 5xxx controllers is
implemented as a block device driver, block/cciss.c (aka, cciss). But
the controller interface is SCSI-3 compatible. The specification says,
"A controller that supports CISS is considered to be a SCSI storage
array controller". A scsi driver for the controllers was discussed
I think that a SCSI cciss driver can be much simpler (and
maintainable) than the block cciss driver (the majority of the code
forging SCSI command can go away, we have the proper sysfs entries for
free, we can handle scsi tape drives easily etc). It would be helpful
for distributions too since they don't need stuff specific to cciss
(such as udev rules).
First of all, thanks, Tomo, for doing this.
There isn't any easy migration path for users. So I think that we need
to keep the block and scsi drivers for cciss for some time (say two
My scsi driver is still in an early stage (I tried to keep the changes
minimum). I can detect logical units, mount a file system, do lots of
I/Os, however, there are lots of TODOs in the management features.
If I can get an ACK from HP about the long-term migration of cciss to
SCSI, I'm happy to keep working on the SCSI cciss driver and maintain
it until HP takes over the driver.
It's been on my to-do list for about as long as I started looking on
the cciss code. However, some thoughts:
- Having cciss using the SCSI infrastructure is indeed far more logical.
Although it looks as if it doesn't support the SCSI spec in full
(ie no conformity claimed in the INQUIRY data) it certainly implements
quite a large subset.
- The error handling in the SCSI infrastructure is far better structured
as that one in the existing cciss driver, so the SCSI driver would
benefit from this.
- Nevertheless, the cciss driver and the corresponding sysfs / device node
layout has become the de-facto standard over the years and it will be
_hard_ to change that.
- However, given that the sysfs information from the cciss driver is quite
rudimentary I doubt if anyone will indeed notice if the _internal_ driver
is a SCSI or a block level driver, as long as the _external_ interface
(ioctl, device-node layout etc) stays the same.
Having said that I think this is the direction it should take:
- Split the existing cciss driver in two parts, one part for the
block-level interface and one for the lower-level device handling bits.
- Redo the patch based on that, so that existing code can be shared
(and fixes there would be included in both drivers).
- Add some hooks/safeguards so that only _one_ interface driver can
This way we would be able keep the existing functionality and allow
users to play around with the new driver.
Long-term we can start moving the driver itself to SCSI, and keeping
the existing cciss block interface only as a wrapper which adjusts
the major:minor numbers; the device-node layout can be handled by udev.
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/