On Tue, Dec 1, 2015 at 6:19 AM, barret rhoden <[email protected]> wrote:
> 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().
>
It seems a lot of extra code for debugging ☺
Also, if I am debugging, I could just use the macro in my module.
Yes, I would have to rebuild the kernel, but it's not that much of a wait.
I would have personally chosen the simpler code given the Pros that come
with it, but anyway.
>
> > +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. =)
>
Since I am currently using dummies in other code, can you check if
something like this pleases the linker, without screwing up with section
size constraints (multiple of object size):
#define INIT_SECTION(sect) char __attribute__((__section__( #sect )))
__init_section_##sect[0]
A better alternative would be weaks for __start_/__stop_. This generates no
linker errors, even though foo is never defined:
extern int __attribute__((weak)) foo[];
int main(void)
{
if (foo)
return 0;
return 1;
}
Look at what GCC (and linker missing relocation) does with rax/eax ☺
00000000004004ed <main>:
4004ed: 55 push %rbp
4004ee: 48 89 e5 mov %rsp,%rbp
4004f1: b8 00 00 00 00 mov $0x0,%eax
4004f6: 48 85 c0 test %rax,%rax
4004f9: 74 07 je 400502 <main+0x15>
4004fb: b8 00 00 00 00 mov $0x0,%eax
400500: eb 05 jmp 400507 <main+0x1a>
400502: b8 01 00 00 00 mov $0x1,%eax
400507: 5d pop %rbp
400508: c3 retq
400509: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
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.
>
That might be a long patch to fix all the places where we assume WAIT means
never NULL.
But I am not against it in principle.
We need to make sure we kill "current" instead of returning NULL, in these
cases.
Otherwise we get panics instead of OOM kills.
--
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.
