On Wed, Nov 25, 2015 at 5:10 AM, barret rhoden <[email protected]> wrote:
> On 2015-11-24 at 14:10 Kevin Klues wrote:
> > I'm curious if we don't want to expose the topology in the same way
> > linux does in /proc so libraries like libnuma can compile and just
> > work. I see the usefulness of this for variables in general, but I'm
> > not sure num_cores should be here (or maybe it's also here in addition
> > to /proc).
>
> I imagine we'll have a #topology device or something that people can
> mount at /proc or wherever. Doing something with a hierarchy in #vars
> would make it a lot more complicated.
>
> I put num_cores in here both as an example and since someone had
> mentioned exporting it the other day (i think).
>
I think topology deserve its own dedicated file and emit code, instead of
simple integers.
but, if we have the struct in the section, directly specify an emit
function, we could fit that as well.
We can then have a set of type specific read/write functions for int, long,
char*, etc..
struct section_var {
const char *name;
void *addr;
int (* read)(void *addr, const char *buffer, size_t size);
int (* write)(void *addr, char *buffer, size_t size);
};
Then the macros can have RO and RW suffixes or prefixes names, and the RO
would will ->write with NULL.
The fully specified form of the macro, would allow the user to use its own
read/write, also because the write could trigger extra code which is
necessary to propagate the new variable value.
But in the simplest form, once we have a predefined set of read/write
functions, it can be as simple as in this example:
https://x20web.corp.google.com/~dlibenzi/var.c
--
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.
