I like Davide's idea of doing the name explicitly. At that point however
I'm not sure I see the advantage of the macro
VARS_ENTRY(foobar, type_int | VARS_HEX),
I'd also rather see a format string, not a fixed type, for controlling
printing. Since we have Plan 9 style arbitrary formats, e.g. %F is a 9p
fcall we can print, formats give us more room to shoot ourselves in the
foot. What fun!
We also have a standard directory-describing struct, Dirtab, which with one
extension we could use.
Hence this proposal:
static Dirtab mystuff[] __vartab = {
{"boot", {(uint64_t)&boot, 0, 0}, 0, 0555, "%x",},
};
OK, I admit, it's less convenient. And it requires we amend the Dirtab to
include a void *aux (for the format). But it gives us arbitrary formats and
you don't have to export all those enums (e.g. VARS_HEX) to every potential
user.
But once you do the first entry, adding entries is easy (I've done it) and
generating entries via a trivial Go program that scans the ELF for symbols
of interest is really easy (ditto).
I still prefer the code over the macro because I can see precisely what is
going on in the code. If someone ever changes the macro for any reason, I
will tend to ass-u-me that the macro has not changed, and that can lead to
hard to find errors.
I agree that the macro can be a good defense against changes, but we're
pretty good at spatch nowadays and that works well too for global language
oriented structural changes.
Either way, this is really good stuff and I agree with Davide and Barret
about their improvements.
ron
On Wed, Nov 25, 2015 at 7:59 AM 'Davide Libenzi' via Akaros <
[email protected]> wrote:
> 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.
>
--
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.
