>
> __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