Which is, oddly enough, what I proposed in May. Tho I didn't name the
field.
Let's do this. I can't get to this for another 2 weeks or so tho (ComicCon
this weekend, road trip next). If someone wants to make a first cut at
this, I won't object. :) If not, I'll do it when I get back.
I presume you envision this simply as another field in Scsi_Request,
leaving the call to scsi_wait_req() the same? That would require
modification to sd, st, sr, osst, scsi_scan, sg... is that about it? The
low-level drivers should be able to ignore this.... am I missing anything?
Does sc_request in the Scsi_Cmnd structure always point back to the
Scsi_Request structure associated with it? All queuecommand() gets is the
Scsi_Cmnd... I'm guessing it does, but I don't immediately see the code to
make this all work....
Matt
On Sun, Jul 28, 2002 at 12:54:48AM -0400, Douglas Gilbert wrote:
> Matt,
> I have no objection to adding a field in Scsi_Request
> called something like 'dxfer_len' (CAM name) that makes
> its intent pretty clear. We probably have to keep
> 'bufflen' there for the time being. 'bufflen' is pretty
> clear in the non scatter gather case (i.e. number of bytes
> in 'buffer') but is confusing in the scatter gather case
> when 'buffer' contains the scatter gather list.
>
> Doug Gilbert
>
>
> Matthew Dharm wrote:
> >
> > ARGH!!
> >
> > Okay search the linux-scsi archives for May 29-30. We've had this
> > discussion before.
> >
> > At that time, I proposed adding a field to indicate the actual amount of
> > data being requested, as opposed to the buffer size. At the time (again,
> > see the archives), I was told that the request_bufflen field _was_ that
> > field.... any case where the request_bufflen didn't match up with the
> > command was a bug and needed to be fixed.
> >
> > So which is it? This needs to be fixed one way or another.
> >
> > Emulated SCSI busses _need_ to know how much data to move. usb-storage has
> > a large table to try to figure it out, but it only gets the correct answer
> > in _most_ cases, not all cases. Only the originator of the command truly
> > knows how much data is going to be moved, so the only mechanism that makes
> > sense is to make the originator of the command indicate that number via
> > some mechanism.
> >
> > Matt
> >
> > On Sun, Jul 28, 2002 at 12:48:03AM +0200, Andries.Brouwer@xxxxxx wrote:
> > > I haven't seen these patches integrated into a kernel yet... have I
> > > just
> > > missed them, or is there some reason they have been rejected?
> > >
> > > > +++ b/drivers/scsi/scsi_scan.c Sun Jul 21 00:55:37 2002
> > > > - 256, SCSI_TIMEOUT+4*HZ, 3);
> > > > + scsi_cmd[4], SCSI_TIMEOUT+4*HZ, 3);
> > >
> > > > +++ b/drivers/scsi/sd.c Sun Jul 21 00:55:44 2002
> > > > - 512, SD_TIMEOUT, MAX_RETRIES);
> > > > + 255, SD_TIMEOUT, MAX_RETRIES);
> > >
> > > There are many more possibilities.
> > > Since the number of hours in a day is very finite, Linus cannot
> > > look at everything, so even if the patch is perfect it can be ignored.
> > >
> > > There is not really a SCSI maintainer, but there are people that are
> > > well-known as active in the SCSI area. You may try to submit via
> > > one of them.
> > >
> > > But then the question is whether these are good patches.
> > >
> > > I booted 2.5.29 earlier this evening and was greeted by
> > > kernel BUG at transport.c: 351 and
> > > kernel BUG at scsiglue.c: 150.
> > > (And the usb-storage module now hangs initializing; rmmod fails,
> > > reboot is necessary.)
> > >
> > > The former BUG_ON wants to have len == srb->request_bufflen.
> > > But I don't know whether that is wise. It is less confusing
> > > when bufflen indicates the size of the buffer available,
> > > rather than the number of bytes you expect to move.
> > > It is not unusual to get one byte more than you asked for,
> > > in case you ask for an odd number of bytes.
> > >
> > > So, maybe these patches aren't clear improvements.
> > >
> > > Andries
> >
> > --
> > Matthew Dharm Home:
> > mdharm-usb@xxxxxxxxxxxxxxxxxx
> > Maintainer, Linux USB Mass Storage Driver
> >
> > I could always suspend a few hundred accounts and watch what happens.
> > -- Tanya
> > User Friendly, 7/31/1998
> >
> >
> > ------------------------------------------------------------------------------------------
> > Part 1.2Type: application/pgp-signature
--
Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx
Maintainer, Linux USB Mass Storage Driver
I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999
pgpKzZkolqlIL.pgp
Description: PGP signature
|
