Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining

[FUJITA Tomonori <tomof@acm.org>]

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
Date: Tue, 24 Jul 2007 20:12:47 +0900

> From: Boaz Harrosh <bharrosh@panasas.com>
> Subject: Re: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
> Date: Tue, 24 Jul 2007 13:01:34 +0300
> 
> > FUJITA Tomonori wrote:
> > > From: Boaz Harrosh <bharrosh@panasas.com>
> > > Subject: [PATCHSET 0/5] Peaceful co-existence of scsi_sgtable and Large IO sg-chaining
> > > Date: Tue, 24 Jul 2007 11:47:50 +0300
> > > 
> > >> As Jens said, there is nothing common to scsi_sgtable and 
> > >> sglists. Save the fact that it is a massive conflict at 
> > >> scsi-ml. They touch all the same places.
> > >>
> > >> Proposed is a simple way out. Two patchsets That produce the
> > >> same output at the end.
> > >>
> > >> One: scsi_sgtable_than_sg-chaining
> > >> Two: sg-chaining_than_scsi_sgtable
> > > 
> > > Hmm, I thought that I've already posted a scsi_sgtable patch working
> > > with sg-chaining together.
> > > 
> > > http://marc.info/?l=linux-scsi&m=118519987632758&w=2
> > > 
> > > I quoted from my mail:
> > > 
> > > ---
> > > I think that the main issue of integrating sgtable and sglist is how
> > > to put scatterlist to scsi_sgtable structure.
> > > 
> > > If we allocate a scsi_sgtable structure and sglists separately, the
> > > code is pretty simple. But probably it's not the best way from the
> > > perspective of performance.
> > > 
> > I was just answering your other mail when this came in so I'll answer
> > here. 
> > This Approach is exactly the scsi_data_buffer approach we both
> > had solutions for. At the time I was all for that approach because it
> > is safer and could be kept compatible to old drivers. (Less work for
> > me) But it was decided against it. So suggesting it again is plain
> > going back.
> 
> Well, the approach to shuffle the entire request setup around was
> rejected. But was the approach to use two data buffers for bidi
> completely rejected?

I should have said that, was the approach to use separate buffer for
sglists instead of putting the sglists and the parameters in one
buffer completely rejected?