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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
