public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <tomof@acm.org>
Cc: linux-scsi@vger.kernel.org, jens.axboe@oracle.com,
	James.Bottomley@SteelEye.com, fujita.tomonori@lab.ntt.co.jp
Subject: Re: [PATCH 0/9] scsi_data_buffer structure (in preparation for bidi)
Date: Sun, 09 Sep 2007 17:09:15 +0300	[thread overview]
Message-ID: <46E3FE8B.8020401@panasas.com> (raw)
In-Reply-To: <20070909045734Y.tomof@acm.org>

On Sun, Sep 09 2007 at 16:47 +0300, FUJITA Tomonori <tomof@acm.org> wrote:
> On Sun, 09 Sep 2007 11:25:57 +0300
> Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>> On Fri, Sep 07 2007 at 0:50 +0300, FUJITA Tomonori <tomof@acm.org> wrote:
>>> This patchset, which I submitted before, adds a new data structure, 
>>> scsi_data_buffer, including everything for data transfer:
>>>
>>> struct scsi_data_buffer { unsigned length; int resid; short sg_count;
>>>  short __sg_count; struct scatterlist *sglist; };
>>>
>>> One scsi_data_buffer structure is embedded in struct scsi_cmnd for 
>>> uni-directional transfer. All the members are just moved from 
>>> scsi_cmnd structure to scsi_data_buffer structure. So nothing is
>>> added to scsi_cmnd structure.
>>>
>>> After applying this patchset, llds must use the scsi data accessors.
>>> This patchset includes some conversation patches (most of them are
>>> patches that Boaz submitted before), however there is still some code
>>> that is needed to be converted.
>>>
>>> Boaz, if you still have other conversation patches, please submit 
>>> them.
>>>
>>> I suspect that nobody cares about some of unconverted llds, which
>>> will be not compilable after this patchset. I'll fix ldds that people
>>>  complain about.
>>>
>>> It's difficult to test this patchset in -mm via scsi-misc. Jens, 
>>> please send this to -mm via the block tree.
>> Sorry for the late response. Just am back from vacation.
>>
>> Tomo please hold with these patches a bit longer the
>> Tree is not ready for it. 
> 
> Then we have no chance to merge scsi_data_buffer into 2.6.24.
> 
I hope to submit all/most of the work this week. If we miss the window
for 2.6.24 than I'm very sorry for that. But I don't think we are 
aloud to break USB storage subsystem.
 
> 
>> Mainly you will totally break USB storage mid-layer. 
>> There is one converted USB driver - microtek.c - that is 
>> currently broken. This is because usb mid-layer still issues 
>> a synchronous REQUEST_SENSE with use_sg == 0. 
>> (And still bangs all over scsi_cmnd members) I have a 
>> complete and somewhat tested solution for the USB stack
>> and all the drivers. as well as lots of other drivers 
>> (see list below). I will submit them group by group during
>> this week and next week. The reason I did not release them
>> yet is because I did not want to do this before the vacation
>> and not be available for debugging.
>>
>> Some of the files I have patches for are:
>>
>> git-diff --stat
>>  drivers/fc4/fc.c                    |   40 ++---
> 
> I think that I fixed fc4 (the patch is in scsi-misc).
> 
Sorry I did not see that one I'll drop it

> 
>>  drivers/scsi/NCR5380.c              |   39 ++--
>>  drivers/scsi/NCR5380.h              |    7 +
>>  drivers/scsi/NCR53C9x.c             |   40 ++---
>>  drivers/scsi/NCR53C9x.h             |    2 -
>>  drivers/scsi/a2091.c                |   36 +---
>>  drivers/scsi/a3000.c                |   15 +--
>>  drivers/scsi/aha1542.c              |   54 ++----
>>  drivers/scsi/arm/acornscsi.c        |   14 +-
>>  drivers/scsi/arm/fas216.c           |    5 +-
>>  drivers/scsi/arm/fas216.h           |    3 +
>>  drivers/scsi/arm/scsi.h             |   34 +---
>>  drivers/scsi/atari_NCR5380.c        |   47 ++---
>>  drivers/scsi/atp870u.c              |  102 ++---------
>>  drivers/scsi/dec_esp.c              |   17 --
>>  drivers/scsi/eata_pio.c             |   12 +-
>>  drivers/scsi/fd_mcs.c               |   36 +---
>>  drivers/scsi/gdth.c                 |    2 +-
>>  drivers/scsi/imm.c                  |   13 +-
>>  drivers/scsi/in2000.c               |   10 +-
>>  drivers/scsi/oktagon_esp.c          |   14 --
>>  drivers/scsi/pluto.c                |    2 +-
>>  drivers/scsi/ppa.c                  |   12 +-
>>  drivers/scsi/qla1280.c              |  348 +++++++++++++++--------------------
> 
> The patchset includes qla1280 conversion.
Yes I saw it I'll drop qla1280.

> 
> 
>>  drivers/scsi/qlogicpti.c            |   54 +-----
>>  drivers/scsi/scsi_error.c           |  114 ++++++++----
> 
> The patchset includes your patch to convert scsi_error.c. What else do
> you want to change?
> 
scsi_error.c is to do with the USB changes I'll be sending
very soon. It's currently in testing.

> 
>>  drivers/scsi/seagate.c              |   17 +-
>>  drivers/scsi/sun3_NCR5380.c         |   42 ++---
>>  drivers/scsi/sun3x_esp.c            |   21 +--
>>  drivers/scsi/wd33c93.c              |   10 +-
>>  drivers/usb/storage/freecom.c       |   14 +-
>>  drivers/usb/storage/isd200.c        |    6 +-
>>  drivers/usb/storage/protocol.c      |  120 +++++-------
>>  drivers/usb/storage/sddr09.c        |    9 +-
>>  drivers/usb/storage/shuttle_usbat.c |   54 +++---
>>  drivers/usb/storage/transport.c     |   95 ++++------
>>  drivers/usb/storage/transport.h     |    2 +
>>  include/scsi/scsi_eh.h              |   17 ++-
>>  38 files changed, 574 insertions(+), 905 deletions(-)
>>
>>
>> If any of these are obsolete and should be removed please
>> say so. Save me the work to submit them.
> 
> I think that nobody cares about some of these drivers and they might
> be even broken. We need to merge the patchset to -mm and then we can
> see what drivers people still care about. And if necessary, we can
> blindly just convert drivers.
If you know of any, specifically than lets send patches to remove them. 
No point in leaving them not compilable. Other wise My conversions are 
not "blindly" and I think are pretty safe. I hope.

Boaz

  reply	other threads:[~2007-09-09 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-06 21:50 [PATCH 0/9] scsi_data_buffer structure (in preparation for bidi) FUJITA Tomonori
2007-09-06 21:52 ` FUJITA Tomonori
2007-09-09  8:25 ` Boaz Harrosh
2007-09-09 13:47   ` FUJITA Tomonori
2007-09-09 14:09     ` Boaz Harrosh [this message]
2007-09-09 14:46       ` FUJITA Tomonori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46E3FE8B.8020401@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tomof@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox