Xen devel - Oct 2007 - __RING_SIZE() macro not aconstant when compiling under windows

When I try and use the __RING_SIZE() macro under windows as the size of
an array, the ddk compiler complains that it''s not a constant
expression. The exact error it gives is

"
c:\projects\xen\xenvbd\xenvbd.h(43) : error C2057: expected constant
expression
"

Is there something special about gcc that would let this work under it
but not under the windows compiler?

Thanks

James

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

> When I try and use the __RING_SIZE() macro under windows as the size of
> an array, the ddk compiler complains that it''s not a constant
> expression. The exact error it gives is
>
> "
> c:\projects\xen\xenvbd\xenvbd.h(43) : error C2057: expected constant
> expression
> "
>
> Is there something special about gcc that would let this work under it
> but not under the windows compiler?
__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...?

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@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> __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@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 2007-10-27 at 21:36 +1000, James Harper wrote:
> When I try and use the __RING_SIZE() macro under windows as the size of
> an array, the ddk compiler complains that it''s not a constant
> expression. The exact error it gives is
> 
> "
> c:\projects\xen\xenvbd\xenvbd.h(43) : error C2057: expected constant
> expression
> "
> 
> Is there something special about gcc that would let this work under it
> but not under the windows compiler?
dunno much about the windows ddk, but does the diff below help?

regards,
dns

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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

> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> "James Harper" <james.harper@bendigoit.com.au>
27.10.07 13:36 >>>
>When I try and use the __RING_SIZE() macro under windows as the size of
>an array, the ddk compiler complains that it''s not a constant
>expression. The exact error it gives is
>
>"
>c:\projects\xen\xenvbd\xenvbd.h(43) : error C2057: expected constant
>expression
>"
>
>Is there something special about gcc that would let this work under it
>but not under the windows compiler?
I would think that this is a compiler bug, especially since (trivial workaround
for you) adding the address-of operator as in

#define __RING_SIZE(_s, _sz) \
    (__RD32(((_sz) - (long)&(_s)->ring + (long)(_s)) /
sizeof((_s)->ring[0])))

makes the code compile (the operator shouldn''t be needed since the
conversion is being done implicitly anyway - otherwise the cast
wouldn''t
work). Since this should be a benign change for all other compilers, it may
be reasonable to change the public header this way.

Jan


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

>dunno much about the windows ddk, but does the diff below help?
Definitely not - typeof() is not a standard construct.

Jan


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

On Mon, 2007-10-29 at 08:54 +0000, Jan Beulich wrote:
> >dunno much about the windows ddk, but does the diff below help?
> 
> Definitely not - typeof() is not a standard construct.
....oops. you''re right. i always reckoned it was in c99.

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@cs.tum.edu
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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