I would also have the macro take the name explicitly, instead of stringifying the var name. This allows to use some namespacing (ala sysctl - foo.moo - given that all the variables are within the same ns), to avoid possible conflicts.
On Wed, Nov 25, 2015 at 5:34 AM, barret rhoden <[email protected]> wrote: > On 2015-11-24 at 14:15 'Davide Libenzi' via Akaros wrote: > > This would have been a bit nicer IMO, if modules wanting to export > > variables, won't need to hack into another file. > > The macro, used locally in the module source files, would populate a > > given section with structs like: > > > > struct var_export_entry { > > const char *name; > > void *addr; > > unsigned long flags; > > }; > > > > Then the init code of the var file would just read those entries and > > populate the var namespace. > > Nice idea; I think I can add that easily... > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
