Date: Wed, 23 Jan 2002 12:26:01 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: "John S. Bucy" <bucy@ece.cmu.edu> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: target mode passthrough Message-ID: <200201231926.g0NJQ1u77579@aslan.scsiguy.com> In-Reply-To: Your message of "Mon, 21 Jan 2002 13:55:43 EST." <20020121135542.C23025@catalepsy.pdl.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> >A number of research projects at the Parallel Data Lab at CMU are >making increasing use of target-mode scsi in FreeBSD to enable >storage-systems research. We have found that hacking support for more >and more scsi commands in the existing target mode driver to be a real >pain. Well, that driver is really only a model. As it stands, most new commands should just fall out into the exception handler to be handled by the userland daemon anyway. >What I'd like to do is write a "target mode passthrough" driver that >would allow all SCBs to be handled by a userland process rather than >in the kernel. I would like to hear from people what they think the >Right Way(tm) to do this might be and what sorts of limitations I can >expect to see. In particular: > >1. Should I try to incorporate this into existing CAM APIs or do > something else? No CAM APIs need to change. All of the CCB types should remain the same, etc. You just need to change the policy of the existing target mode driver to not bother to handle reads, writes, and inquiry request specially in the kernel. If this became the default "sample implementation", I'd be fine with that. >2. Can we support tagged queueing? Sure. It may already work in the -stable aic7xxx driver, but if not, it's only because I haven't pushed my latest driver into the FreeBSD tree yet. I would expect the qlogic driver to just work already. >3. Will disconnecting on every command while its queued to userspace >cause problems either locally or with the initiator? This really only applies to parallel SCSI. The target can only disconnect is the initiator has given it the privledge to disconnect. Although there will be increased latency due to going all the way to userland to handle a request, this shouldn't be too big a deal if you are using tags and have a sufficient number of tags outstanding. >4. What degree of control over disconnection do the HBA drivers >support? It's been a while, but I believe you can specify during your enable-lun call whether disconnection should be performed by the target (with the caveat about privledge noted above). I can't say which drivers honor this though. On the initiator side, you can use camcontrol to enable or disable disconnection. -- Justin 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?200201231926.g0NJQ1u77579>