>Hi Stephane,
Hi Ralf,
>
>On 01/12/2021 00:20, Stephane Viau wrote:
>> +/* Memory & peripherals */
>> +#define CONFIG_INMATE_REGIONS_NUM (1)
>> +#define CONFIG_INMATE_REGIONS \
>> + MEM_REGION_RWXL(0xc0000000, CONFIG_INMATE_BASE, MB(16)), /* RAM */
>> \
>
>just picking out this aspect here. I found a way how we can even get rid
>of CONFIG_INMATE_REGIONS_NUM.
>
>The problem is, we need to know the storage size in advance, in order to
>declare the array. This is why you have CONFIG_INMATE_REGIONS_NUM
>definition.
>
>But with your new macros, we have the definition inside
>CONFIG_INMATE_REGIONS, and we can easily reuse it: We can first use it
>for calculating the storage size, and later we can use it inside the
>definition. Have a look at the following snippet. The compiler eats it.
>I guess you should get the basic idea:
>
>----8<----
>
>#include <stdio.h>
>
>struct foo {
> int a;
> int b;
>};
>
>#define MEMBER(A, B) \
> { .a = A, \
> .b = B, \
> }
>
>#define MEMBERS \
> MEMBER(1, 2), \
> MEMBER(3, 4), \
> MEMBER(5, 6),
>
>#define MEMBERS_NUM \
> (sizeof((struct foo[]){MEMBERS}) / sizeof(struct foo))
>
>struct foo asd[MEMBERS_NUM] = {
> MEMBERS
>};
>
>int main(void)
>{
> printf("%u\n", MEMBERS_NUM);
>}
>
>
>----8<----
>
>This way, we could get rid of all the *_NUM-macros, and have the values
>calculated automatically (and correctly). What do you think?
Kinda cool!.. I'll update and repost soon.
BR,
Stephane.
>
>Thanks
> Ralf
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/PAXPR04MB88639A2375741D3A2AD88E90A7689%40PAXPR04MB8863.eurprd04.prod.outlook.com.
