linux-kernel - Re: HP (Compaq) Smart Array 5xxx controller SCSI driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080724101953R.fujita.tomonori@lab.ntt.co.jp>
Date:	Thu, 24 Jul 2008 10:32:45 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	scameron@...rdog.cca.cpqcorp.net
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: HP (Compaq) Smart Array 5xxx controller SCSI driver

CC'ed linux-scsi, why did you drop it?

On Tue, 22 Jul 2008 12:57:29 -0500
scameron@...rdog.cca.cpqcorp.net wrote:

> James Bottomley wrote:
> > Actually, I think we can make one (which is really required ... it's a
> > lot of pain to move device nodes, just look at libata).  It should be
> > child's play to come up with a udev rule that simply does extra symbolic
> > links from /dev/cciss<n>c<n>p<n> to whatever the sd device is.  That
> > should hide a lot of the problem.
> > 
> > The other issue is plugging the management ioctl in, but that can be
> > done via scsi_host->ioctl.
> > 
> > James 
> 
> Another thing which would help would be to expose device type 0x0C (raid
> controller) and let sg bind to it.

Yeah, it's possible (and might be useful). Actually, my first version
exposed a RAID device. I'm not sure yet what's the best way to expose
CCISS logical and physical units (including a RAID device) to SCSI
logical unit numbers.


> It is a little hard to see what Tomo's patch does, as it's all in one step.
> 
> In the times I've converted cciss to be a SCSI driver in the past 
> the steps were more or less as follows (from memory):
> 
> 1) copy the driver files into drivers/scsi,
> 2) rename everything, change the Makefile/Kconfig stuff to add in the new code.
> 3) take out the stuff that makes it a block driver

Sounds reasonable, I did the similar.


> 4) add a CCISS_REPORT_LOGICAL_LUNS call into the scsi tape device discovery
> code, expose those devices, add the controller itself in to the list of devices
> artificially (8-byte lun address == all zeroes).
> 
> At this point the driver will work, but performance will completely suck.
> 
> 5) switch the tape code to use the block side command allocator, (cmd_alloc()
> in cciss.c) and ditch the rinky-dink tape code command allocator
> (scsi_cmd_alloc() in cciss_scsi.c) and jack up the number of commands 
> and queue depth the SCSI side of the driver will support to something 
> reasonable.

Yeah, right. I've not cleaned up this part yet. We need to rework on
command allocation and queue depth management. I think that the scsi
subsystem enables us to simplify (and improve) the queue depth
management code.


> At this point performance will stop completely sucking.
> 
> 6) rip out a bunch of the block side code.
> 7) (I've never actually done this step) move the necessary ioctls to the scsi
> side of the driver.
> 
> The tape code has stuff for hot-plugging of things, sort of (and I sent up some
> patches some time ago to make that better awhile ago, but they seemed to get
> ignored for whatever reason.) This would need to change to be a bit more
> careful (look at page 0x83 serial numbers to find what devices were
> new/changed/gone rather than just looking at device type, which is what it's
> doing now.  BTW, I have patches in the works for the block driver to improve
> the behavior of rebuild_lun_table, which currently sucks in the brute force way
> that it does things.  This patch also removes the duplicated discovery
> cdde from cciss_init_one, and has cciss_init_one just call rebuild_lun_table(),
> but I digress.)

Yeah, I think that the device scanning code is an area that we need to
rework on. We need to make it work nicely with the scsi infrastructure.


> In any case, I don't think what I described above was what was done here... It
> looks like the tape code was ditched, and new code that does almost the same
> thing was written.  Maybe there was a good reason for that, I don't know.

I didn't integrate the tape code because it was just an RFC. I just
read the cciss code and converted it to a scsi driver. Of course, we
need to integrate the tape support to a scsi cciss driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/