Date: Wed, 29 Mar 1995 13:52:37 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: Preserving "record structure" during device writes Message-ID: <199503291852.NAA00423@hda.com> In-Reply-To: <9503291833.AA20122@cs.weber.edu> from "Terry Lambert" at Mar 29, 95 11:33:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > > > I'm resurrecting my SCSI target stuff from 386bsd. > > > > If processor A tries to read 32 bytes from processor B, and processor > > B only sends 8, physio keeps looping on the read until we either timeout > > or receive the full 32 bytes (four transfers). > > > > What is the right way to handle this? My inclination is that > > we want to return a short read, but then I can't just use rawread and > > rawwrite. > > The short reads are necessary; remember the scanner stuff? No, I don't. Which scanner stuff? The only scanner firmware I've written sends a header block saying what the blocking factor is so that both ends know exactly what to expect for data blocks. It is specifically done that way to be portable across systems with this sort of problem. See, I've actually written some of the stupid code that you curse when you have to interface to a given device. None of the scsi code currently return short lengths even if residual code is handled in the drivers (and it is spotty, I looked this morning) since they all go through rawread and rawwrite which unconditionally loop on short reads. This probably only matters for essentially raw devices such as a scanner, the processor device, or the unknown device. HOST ADAPTER CODE "OWNERS": Locally I've added a flag similar to the bounce buffer flag that says that residual lengths are handled by the driver. I'll probably commit this code soon so you may want to look at fixing your resid code. The "xs->resid" field is supposed to be the same as bp->b_resid: the amount of data left untransferred. If you're in the code and know how to fix it please do so. I have fixes for the 154x and the 174x. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503291852.NAA00423>