[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.