Re: [Xen-devel] block ring interface: nr_segments = 0 results in BLKIF_RSP_ERROR

["Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>]

See dispatch_rw_block_io in blkback.c:

        /* Check that number of segments is sane. */
        nseg = req->nr_segments;
        if (unlikely(nseg == 0) ||
            unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
                DPRINTK("Bad number of segments in request (%d)\n", nseg);
                goto fail_response;
        }

Why is it important that the backend report that a request for
zero-length i/o is okay?

a.

On 8/24/06, Chris Youb <chris_youb@xxxxxxxx> wrote:
> I am currently developing a blkfront.c for a custom OS over Xen 3.0.2-2.
> Typical I/O is working, however, I ran into an error while testing a corner
> case.
>
> On standard I/O, where  { 1 <= nr_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST
> } blkif_int()'s bret->status returns BLKIF_RSP_OKAY.
>
> Yet when { nr_segments == 0 } blkif_int's bret->status is non-zero. (Yes I
> realize this is an I/O call of zero-length.)
>
> I checked the documentation and section "8.2.2 Block ring interface" states
> the following but doesn't exclude 0:
>
> "nr_segments
>      number of segments for scatter / gather IO described by this request"
>
> 1) Is it possible there is a problem w/ my front-end driver (ie does anyone
> else see this behaviour)?
>
> 2) If this is back-end related, shouldn't it just return BLKIF_RSP_OKAY?
>
>
>  ________________________________
> Now you can have a huge leap forward in email: get the new Yahoo! Mail.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel