All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: FUJITA Tomonori <tomof@acm.org>
Cc: jens.axboe@oracle.com, James.Bottomley@SteelEye.com,
	akpm@osdl.org, michaelc@cs.wisc.edu, hch@infradead.org,
	linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
	bhalevy@panasas.com
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 29 Apr 2007 18:48:59 +0300	[thread overview]
Message-ID: <4634BE6B.3000808@panasas.com> (raw)
In-Reply-To: <200704281948.l3SJm9jS001428@mbox.iij4u.or.jp>

FUJITA Tomonori wrote:
> From: Boaz Harrosh <bharrosh@panasas.com>
> Subject: [PATCH 4/4] bidi support: bidirectional request
> Date: Sun, 15 Apr 2007 20:33:28 +0300
> 
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index 645d24b..16a02ee 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -322,6 +322,7 @@ struct request {
>>      void *end_io_data;
>>
>>      struct request_io_part uni;
>> +    struct request_io_part bidi_read;
>>  };
> 
> Would be more straightforward to have:
> 
> struct request_io_part in;
> struct request_io_part out;
> 

Yes I wish I could do that. For bidi supporting drivers this is the most logical.
But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on
the hotish paths, this means we will need a pointer to a uni request_io_part.
This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
     specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
     very bad spot already, and I have a short term fix for it in the SCSI-bidi patches
     (not sent yet) but a more long term solution is needed. Once such hacks are
     cleaned up we can do what you say. This is exactly why I use the access functions
     rq_uni/rq_io/rq_in/rq_out and not open code access.

> 
>>  /*
>> @@ -600,6 +601,34 @@ static inline struct request_io_part* rq_uni(struct request* req)
>>      return &req->uni;
>>  }
>>
>> +static inline struct request_io_part* rq_out(struct request* req)
>> +{
>> +    WARN_ON_BIDI_FLAG(req);
>> +    return &req->uni;
>> +}
>> +
>> +static inline struct request_io_part* rq_in(struct request* req)
>> +{
>> +    WARN_ON_BIDI_FLAG(req);
>> +    if (likely(rq_dma_dir(req) != DMA_BIDIRECTIONAL))
>> +        return &req->uni;
>> +
>> +    if (likely(req->cmd_flags & REQ_BIDI))
>> +        return &req->bidi_read;
>> +
>> +    return &req->uni;
>> +}
>> +
>> +static inline struct request_io_part* rq_io(struct request* req,
>> +                                            enum dma_data_direction dir)
>> +{
>> +    if (dir == DMA_FROM_DEVICE)
>> +        return rq_in(req);
>> +
>> +    WARN_ON( (dir != DMA_TO_DEVICE) && (dir != DMA_NONE) );
>> +    return &req->uni;
>> +}
> 
> static inline struct request_io_part* rq_io(struct request* req)
> {
> 	return (req is WRITE) ? &req->out : &req->in;
> }

Again I'm all for it. But this is a to deep of a change. Too many things changing
at once. If we keep the access functions than it does not matter, we can do it later.

Boaz


  reply	other threads:[~2007-04-29 15:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-15 17:17 [PATCH 0/4] bidi support: block layer bidirectional io Boaz Harrosh
2007-04-15 17:25 ` [PATCH 1/4] bidi support: request dma_data_direction Boaz Harrosh
2007-04-15 17:31 ` [PATCH 2/4] bidi support: fix req->cmd == INT cases Boaz Harrosh
2007-04-15 17:32 ` [PATCH 3/4] bidi support: request_io_part Boaz Harrosh
2007-04-29 15:49   ` Boaz Harrosh
2007-04-15 17:33 ` [PATCH 4/4] bidi support: bidirectional request Boaz Harrosh
2007-04-28 19:48   ` FUJITA Tomonori
2007-04-29 15:48     ` Boaz Harrosh [this message]
2007-04-29 18:49       ` James Bottomley
2007-04-30 11:11         ` Jens Axboe
2007-04-30 11:53           ` Benny Halevy
2007-04-30 11:59             ` Jens Axboe
2007-04-30 14:52               ` Douglas Gilbert
2007-04-30 14:51                 ` Jens Axboe
2007-04-30 15:12                   ` Benny Halevy
2007-05-01 18:22                   ` Boaz Harrosh
2007-05-01 18:57                     ` Jens Axboe
2007-05-01 19:01                       ` FUJITA Tomonori
2007-04-30 13:05           ` Mark Lord
2007-04-30 13:07             ` Jens Axboe
2007-05-01 19:50           ` FUJITA Tomonori
2007-05-03 17:42             ` Boaz Harrosh
2007-05-04 13:55               ` FUJITA Tomonori
2007-04-16 18:03 ` [PATCH 0/4] bidi support: block layer bidirectional io Douglas Gilbert
2007-04-17  9:32   ` Boaz Harrosh

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=4634BE6B.3000808@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=bhalevy@panasas.com \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.