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

Re: [Xen-devel] __RING_SIZE() macro not aconstant when compiling under w

To: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] __RING_SIZE() macro not aconstant when compiling under windows
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sat, 27 Oct 2007 16:25:06 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 27 Oct 2007 08:25:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01249CD1@trantor>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D01249CD0@trantor> <200710271420.47630.mark.williamson@xxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01249CD1@trantor>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
> In linux-2.6-xen-sparse/drivers/xen/blkfront/block.h is this:
>
> "
> #define BLK_RING_SIZE __RING_SIZE((blkif_sring_t *)0, PAGE_SIZE)
>
> ...
>
> struct blkfront_info
> {
>   ...
>   struct blk_shadow shadow[BLK_RING_SIZE];
>   ...
> "

Oh right, sorry, missed that.  That certainly ought to be easy for the 
compiler to evaluate at compile time though since it's just a simple 
calculation involving constant values.  Maybe your windows compiler still 
doesn't like this, I guess.

> Which I have to implement in some fashion to get the vbd working under
> Windows. For now, i'm just using a pointer instead of an array and am
> allocating the memory at runtime.

Yeah, that's what I'd do :-)

> I've almost got vbd reads going, but I'm pretty sure that there's
> currently more race conditions than I can poke a stick at... it seems to
> go okay until I put a partition table on the virtual disk...
>
> Btw, can anyone explain why the blk_shadow struct has a
> 'blkif_request_t' in it, when it only uses the id field?

The recovery code copies the complete contents of the shadow request into a 
new request:

                /* Grab a request slot and copy shadow state into it. */
                req = RING_GET_REQUEST(
                        &info->ring, info->ring.req_prod_pvt);
                *req = copy[i].req;

The shadow ring is not necessary for normal operation, but you need it to 
recover from a disconnection e.g. in the event of a suspend / resume or a 
driver domain crash.  Storing a separate shadow structure was intended to 
ensure that even if a driver domain crashed and corrupted shared memory it 
would still be possible to correctly requeue the structures.

> Also, in the same blk_shadow struct, the 'request' field is of type
> unsigned long, but is treated as a pointer to a 'struct request'...
> seems wrong to me.

I've no idea.  It's a genuine dereferenceable virtual address so I've no idea 
why we wouldn't want to just treat it as a pointer.  I suspect it may be a 
legacy thing that's no longer necessary, in which case a cleanup patch would 
probably be accepted!

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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