On 2015-11-30 at 21:54 'Davide Libenzi' via Akaros wrote:
> 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.
I agree that it definitely is simpler without dynamically adding and
removing.
> 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.
The dynamic addition isn't for modules - it's for debugging. If you
know a variable exists and you want to see its value, this is an easy
way to get access to the variable without rebuilding the kernel with a
DEVVARS_ENTRY().
> +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☺
Yes, it's nice to have the symbols present. =)
However, I do want the "." entry to be in the devtab too. I guess I
could build the entry at runtime, but that didn't seem worth it, and
semantically it didn't make as much sense to me. Also, when this code
was static-only, I didn't even use any kmallocs, and simply used the
devvars section for the entire devtab.
> > + 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.
kmalloc(x, KMALLOC_WAIT) cannot return NULL, currently. It sounds like
you want to change that, but that can be a subject for discussion when
we fix the memory allocator.
I originally did just a kmalloc, but checkpatch yelled at me and
suggested I use a kmalloc_array(). So I added that.
> 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 😉
You could store it in the cloud! =)
> I see we don't support write, which would be pretty handy
> with /proc-like configurations.
I considered that too dangerous for now. Creating variables is also
dangerous, but a little less. We can always add write support in the
future.
Barret
--
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.
