On 2015-11-05 at 14:20 "'Davide Libenzi' via Akaros" <[email protected]> wrote: > Here is what I was thinking. > There is an VM area of N pages, at KMSG within kernel only area, and > at UMSG at user VM space. > The user VM space [UMSG, UMSG+N] is out of mmap() reach. > Userspace has an API we give them to create a mailbox, which turns > into a syscall. > The syscall would get the necessary pages, find a free spot X in > [KMSG, KMSG+N], map them there, as well as at UMSG + (X - KMSG). > To deliver an event to user mailbox pointer P, the kernel will use (P > - UMSG + KMSG). > No need to swap CR3. > The mailbox destruction would undo the mapping, and the struct proc > will have to track the mappings as well, so that a process > destruction can undo them as well.
I think there are a couple difficulties with this. One is that some mailboxes consist of pointers to other user memory (requiring more mappings), and those grow and shrink over time. Also, some mailboxes are statically declared and exist in procdata, and there might be a bootstrap issue with dynamically allocating them (though since they are in procdata, we might be able to get by with having the kernel use another mapping). Another issue is that we don't just deref the memory for the mailbox. We also look at the event_queue * for it's flags and whatnot. 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.
