Date: 20 Dec 2000 02:02:55 -0500 From: Nat Lanza <magus@cs.cmu.edu> To: freebsd-scsi@freebsd.org Subject: Asynchronous commands for the passthrough driver Message-ID: <uoc4rzzmv6o.fsf@hurlame.pdl.cs.cmu.edu>
next in thread | raw e-mail | index | archive | help
I'd like to add support for asynchronous commands to the pass driver. Right now, the CAMIOCOMMAND ioctl is completely synchronous -- the caller is put to sleep until the command it passed through is done. This is fine for basic use of the passthrough driver, but it's a problem for anything that wants to make use of command queuing from userland. Most of the work involved in doing this is fairly simple, but I'd like to get opinions on what the right interface is for an application to discover that commands it issued have finished. It'd be unfortunate to spend a few days hacking on this and debugging it only to discover that nobody likes the interface I chose. The simplest solution, and the one I'm currently considering, would be to add two new ioctls to the pass driver, CAMIOSENDCOMMAND and CAMIOFETCHCOMMAND, and maintain a per-instance queue of completed but uncollected CCBs. The first ioctl would enqueue a CCB to the device, passing along a completion function that would add the result CCB to the pass queue, and return immediately without sleeping the caller. The second ioctl would return the first completed CCB on the pass queue if there are any CCBs to return, and would either sleep or return EAGAIN if the queue is empty. Alternately, notification could be done through kqueue or maybe a poll() on the /dev/pass<n> device. An additional complication is the issue of data copies for read/write requests. In the synchronous case, things are simple -- the application making the request is sleeping, so the CAM layer is free to copy data to/from the application-provided buffer without worrying about what the application might have done to that buffer in the meantime. If the application isn't sleeping while the request is being processed, there's the possibility that the specified buffer isn't available when the CAM layer wants to do the data copy -- maybe that buffer is gone, or maybe the application has exited. Thoughts? --nat -- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?uoc4rzzmv6o.fsf>