Re: [PATCH] hptiop: backout ioctl mess

[Douglas Gilbert <dougg@torque.net>]

Arjan van de Ven wrote:
> On Mon, 2006-07-31 at 10:53 +0800, HighPoint Linux Team wrote:
>> Christoph Hellwig wrote:
>>> The hptiop just got merged with a horrible amount of really bad ioctl
>>> code that is against the standards for new scsi drivers.  This patch
>>> backs it out (and fixes a small bug where scsi_add_host is called to
>>> early).  We can re-add proper APIs once we agree on them.
>> What is the standard implemetation of private ioctls for scsi drivers?
>> Thanks.
> 
> Hi,
> 
> the real answer is: try really hard to use generic ioctls for your
> functionality. 

Now there is an idea :-) Pick a vendor specific opcode
like 0xff (and maybe have a module parameter to override
it to something else) and then use the SG_IO ioctl to
send "highpoint" specific SCSI commands that provide
the same functionality within the LLD that Christoph
just stripped out.

One problem with this approach is interacting with the
LLD in the absence of any (real) SCSI devices. It shouldn't be
too hard to trick the mid level into believing there are
SCSI devices connected (see the scsi_debug driver). May
I suggest a LUN slightly above the WLUN range (e.g.
49409+10). The fake device could then be created with:
# cd /sys/class/scsi_host/host0
# echo "- - 49419" > scan

The fake device would need to respond to an INQUIRY and a few
other simple SCSI commands to keep the mid-level happy.
May I also suggest the "processor" peripheral device type
which stops other ULDs getting involved. Then you can talk
to the LLD via a sg device node.

What exactly do you need private ioctls for?
> It's quite possible that there is a generic way to do the same thing
> already, or something that can easily be extended to do what you need...

Is the above generic enough?

Doug Gilbert