On Mon, Nov 30, 2015 at 1:18 PM, Barret Rhoden <[email protected]> wrote:
> + * #vars device, exports read access to select kernel variables. These
> + * variables are statically set.
> + *
> + * To add a variable, add a DEVVARS_ENTRY(name, format) somewhere in the
> kernel.
> + * The format is a string consisting of two characters, using a modified
> version
> + * of QEMU's formatting rules (ignoring count): [data_format][size]
> + *
> + * data_format is:
> + * x (hex)
> + * d (decimal)
> + * u (unsigned)
> + * o (octal)
> + * c (char) does not need a size
> + * s (string) does not need a size
> + * size is:
> + * b (8 bits)
> + * h (16 bits)
> + * w (32 bits)
> + * g (64 bits)
> + *
> + * e.g. DEVVARS_ENTRY(num_cores, "dw");
> + *
> + * Another thing we can consider doing is implementing create() to add
> variables
> + * on the fly. We can easily get the address (symbol table), but not the
> type,
> + * unless we get debugging info. We could consider a CTL command to
> allow the
> + * user to change the type, though that might overload write() if we also
> allow
> + * setting variables. */
>
IMHO it doesn't makes a lot sense the dynamic add/remove, given that we do
not support dynload modules.
Makes code quite a bit simpler (no need for locking), and a few functions
can go.
What would a possible use case be for adding variables at runtime?
They either exist as globals, or, if they come up as dynamic things (say a
TCP connection), they better be handled by the module which creates them,
within its own namespace.
+struct dirtab __attribute__((__section__("devvars")))
> + __devvars_dot = {".", {0, 0, QTDIR}, 0, DMDIR | 0555};
Do you really need this? Instead of adding, finding, ad swapping, you can
just alloc an array +1 size, and create the proper entry at [0].
I know why you added it. Without that, with zero entries in the section,
the __start_/__stop_ symbols are not defined and link fails☺
+
> +/* Careful with this. c->name->s is the full path, at least sometimes. */
> +static struct dirtab *find_var_by_name(const char *name)
> +{
> + for (size_t i = 0; i < nr_vars; i++)
> + if (!strcmp(vars_dir[i].name, name))
> + return &vars_dir[i];
> + return 0;
> +}
>
This could go, with the "." thing added at runtime, and no dynamic
add/remove of vars.
> +
> +static void vars_init(void)
> +{
> + /* If you name a section without a '.', GCC will create start and
> stop
> + * symbols, e.g. __start_SECTION */
> + extern struct dirtab __start_devvars;
> + extern struct dirtab __stop_devvars;
> + struct dirtab *dot, temp;
> +
> + nr_vars = &__stop_devvars - &__start_devvars;
> + vars_dir = kmalloc_array(nr_vars, sizeof(struct dirtab),
> KMALLOC_WAIT);
> + if (!vars_dir)
> + error(ENOMEM, "kmalloc_array failed, nr_vars was %p",
> nr_vars);
>
What's the story? KMALLOC_WAIT can or cannot return NULL? ☺
I know, this is _array(), but I IMO here we could just kmalloc(a * b), and
lose the NULL check.
If we are overflowing the address space with a*b as dirtabs at init, I
don't see where the kernel data and code can be stored 😉
I see we don't support write, which would be pretty handy with /proc-like
configurations.
--
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.
