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: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] __RING_SIZE() macro not aconstant when compiling under windows
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sat, 27 Oct 2007 23:35:59 +1000
Delivery-date: Sat, 27 Oct 2007 06:36:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200710271420.47630.mark.williamson@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgYnFfY0F7PoHQdTfuhE/K6f/8tJwAABUMw
Thread-topic: [Xen-devel] __RING_SIZE() macro not aconstant when compiling under windows
> 
> __RING_SIZE() isn't necessarily plain constant - it does calculations.
In
> practice, these can typically be evaluated at compile time (if sz is a
> constant).  I don't know the C spec well enough to know if it's
> appropriate
> to reject this...
> 
> But __RING_SIZE isn't (as far as I know) actually used anywhere to
size
> arrays?  It's used internally by the other macros in ring.h to set up
> various
> book keeping.  So I'm not sure that you should necessarily need to use
the
> macro this way...?

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];
  ...
"

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.

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?

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.

Thanks

James


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