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-next>] [day] [month] [year] [list]

Message-ID: <20080723155005.GF8833@beardog.cca.cpqcorp.net>
Date:	Wed, 23 Jul 2008 10:50:05 -0500
From:	scameron@...rdog.cca.cpqcorp.net
To:	linux-kernel@...r.kernel.org
Cc:	James.Bottomley@...senPartnership.com, mike.miller@...com,
	fujita.tomonori@....ntt.co.jp
Subject: Re: HP (Compaq) Smart Array 5xxx controller SCSI driver

Fujita Tomonori wrote:
> I created symbolic links (neat udev rules can do automatically).
> 
> clover:/home/fujita# ls -l /dev/cciss/
> total 0
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d0 -> /dev/sde
> lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p1 -> /dev/sde1
> lrwxrwxrwx 1 root root 9 2008-07-23 21:39 c0d0p2 -> /dev/sde2
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d1 -> /dev/sdf
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d2 -> /dev/sdg
> lrwxrwxrwx 1 root root 8 2008-07-23 21:38 c0d3 -> /dev/sdh
> 
> The symbolic links enable users to mount the device as before.
> 
> hpacucli seems to work (I didn't try all the commands but the point is
> that we can provide the ioctl compatibility): 

That's pretty neat, I'm surprised that works.  Obviously
you've got the needed ioctls already done. 

I bet if you deleted all the logical drives it wouldn't work
anymore (because /dev/cciss/c0d0 -> /dev/sde would disappear.)

A way around that would be to present a device to the linux
kernel with 8-byte LUN address of all zeroes mapped to some
bus/target/lun.  When the SCSI scan happens and the inquiry
is sent down to this address, the RAID controller will respond.
Then let sg bind to that, and get ACU to use the sg device.
(I hope it's clear what I'm saying.)

I don't know if the udev rules can be made smart enough to
point /dev/cciss/c0d0 at the sg device if there are no 
logical drives, and at the first logical drive if there 
is at least one.   In the longer term, ACU would have to 
be changed to use that sg device always rather than using
/dev/cciss/c0d0.

In the cciss driver, we always present /dev/cciss/c0d0
whether there are any logical drives or not for this reason,
a rather clunky solution.

-- steve
--
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/