linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	James Bottomley <James.Bottomley@SteelEye.com>,
	linux-scsi <linux-scsi@vger.kernel.org>
Cc: Pete Wyckoff <pw@osc.edu>, Benny Halevy <bhalevy@panasas.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [0/4 ver2] Last 3 patches for bidi support
Date: Thu, 08 Nov 2007 18:49:46 +0200	[thread overview]
Message-ID: <47333E2A.7020307@panasas.com> (raw)
In-Reply-To: <4730ACAA.2060007@panasas.com>

On Tue, Nov 06 2007 at 20:04 +0200, Boaz Harrosh <bharrosh@panasas.com> wrote:
> [1]
> I propose a small change to scsi_tgt_lib.c that will make
> tgt completely neutral to the scsi_data_buffer patch. And will
> make it all that more ready for bidi, too. TOMO is this OK?
> 
> (Can you do without the GFP_KERNEL allocation flag? It could
> make the code a bit more simple)
> 
> [2]
> scsi_data_buffer patch. 
> As requested by TOMO the all patch is squashed into one, 600 
> and some lines. TOMO if it makes you happy, OK, here it is.
> 
> There is one hunk from libsrp.c that I really hate. and from what 
> I understand of the code, only the "request_bufflen =" is really used, 
> All users of "request_buffer = addr" pass NULL, as far as I can see.
> If you would like to make me happy, and it is at all possible, please 
> clean it.
> 
> [3]
> Once scsi_data_buffer is in, then scsi bidi support can be applied. 
> (Block bidi was already merged 3 kernels ago). It makes no changes
> to scsi_cmnd and only adds some, not-at-all-dangerous, code to scsi_lib.
> So I don't see any reason to wait. please all review.
> 
> If ACKed by all parties and applied for inclusion for 2.6.25, 
> then they will have a long time to sit in MM and collect
> compilation breakage reports from ARCHs we never compiled.
> 
> I wish these make everybody happy this time
> 
> Boaz Harrosh
> 

Version 2, fixed as of Tomo's comments. Thanks Tomo.

[0]
   Remove dead code from sd.c & sr.c. It was conceived by programmers
   in the passed that rq_data_dir() could perhaps be expanded to 2 bits
   and return READ/WRITE/BIDI. But we have decided long ago that a bidi
   request is when blk_bidi_rq() == true, and in that case 
   rq_data_dir() == WRITE. So now we can be sure of what the compiler knew
   for a long time. (The future is already here)

[1] [2] [3]
See above

I must insist again they should have time to sit in -mm. 
For posible compilation breakage of other ARCHs.

Boaz


  parent reply	other threads:[~2007-11-08 16:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-06 18:04 [0/3] Last 3 patches for bidi support Boaz Harrosh
2007-11-06 18:16 ` [PATCH 1/3] scsi_tgt_lib: Use scsi_init_io instead of scsi_alloc_sgtable Boaz Harrosh
2007-11-08  3:13   ` FUJITA Tomonori
2007-11-08  8:32     ` Benny Halevy
2007-11-08 13:04       ` FUJITA Tomonori
2007-11-08 14:01         ` Boaz Harrosh
2007-11-08 14:20           ` FUJITA Tomonori
2007-11-06 18:19 ` [PATCH 2/3] scsi_data_buffer Boaz Harrosh
2007-11-08  3:14   ` FUJITA Tomonori
2007-11-08  9:24     ` Boaz Harrosh
2007-11-08 13:03       ` FUJITA Tomonori
2007-11-08 13:53         ` Boaz Harrosh
2007-11-08 13:44   ` Boaz Harrosh
2007-11-08 13:54     ` Jens Axboe
2007-11-08 14:17       ` Boaz Harrosh
2007-11-06 18:23 ` [PATCH 3/3] SCSI: bidi support Boaz Harrosh
2007-11-06 18:25 ` [0/3] Last 3 patches for " Mike Christie
2007-11-06 18:38   ` Boaz Harrosh
2007-11-08  3:13     ` FUJITA Tomonori
2007-11-08 16:49 ` Boaz Harrosh [this message]
2007-11-08 16:56   ` [PATCH 1/4] sr/sd: Remove dead code Boaz Harrosh
2007-11-08 16:57   ` [PATCH 2/4] tgt: Use scsi_init_io instead of scsi_alloc_sgtable Boaz Harrosh
2007-11-08 16:59   ` [PATCH 3/4] scsi_data_buffer Boaz Harrosh
2007-11-13  6:06     ` Andrew Morton
2007-11-13  6:40       ` FUJITA Tomonori
2007-11-13  7:07         ` Andrew Morton
2007-11-13  7:26           ` FUJITA Tomonori
2007-11-13  9:17         ` Boaz Harrosh
2007-11-08 17:03   ` [PATCH 4/4] SCSI: bidi support Boaz Harrosh
2007-11-09 21:15     ` Kiyoshi Ueda
     [not found]       ` <47383020.8010108@panasas.com>
2007-11-12 19:52         ` Kiyoshi Ueda

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=47333E2A.7020307@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=bhalevy@panasas.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pw@osc.edu \
    /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;
as well as URLs for NNTP newsgroup(s).