WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: More virtio users

On Mon, 2007-06-11 at 09:33 +0200, Jens Axboe wrote:
> On Mon, Jun 11 2007, Rusty Russell wrote:
> > So the problem is that I'd like to handle all of them, but I'm not clear
> > what requests my device can get.  I can't see a source of any other type
> > of request.
> 
> The other main request type is blk_pc_request(). In the data setup it's
> indentical to blk_fs_request(), there's a bio chain off ->bio. It's a
> byte granularity entity though, so you should check ->data_len for the
> size of it. ->cmd[] holds a SCSI cdb, which is the command you are
> supposed to handle.

SCSI?  I'm even more lost now.

Q: So what *are* the commands?
Q: Who puts them in my queue?

I have *never* seen anything but an fs request come through to my
driver.

> Perhaps you are misunderstanding what the tag is? The tag is a unique
> identifier for a pending request, so you will by definition never have
> requests sharing a tag value.

Yes, I started to suspect that.

> But the tag is not to be considered as
> ordered, unless it has the barrier flag set as well. So you only need to
> serialize on the device side when blk_barrier_rq() is true.

blk_barrier_rq(req) is never true.  I put a BUG_ON(blk_barrier_rq(req))
in my code and booted.  This is using the device as a root ext3
filesystem.

I reverted all the tag changes, still no barriers.  I added
"blk_queue_ordered(vblk->disk->queue, QUEUE_ORDERED_DRAIN, NULL);",
still no barriers.

Dazed and confused,
Rusty.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel