Security and IPC is hard.... Shared memory is difficult. Network sockets (localhost.localdomain) is a good bet.
Asking about assigning a specific core to a process/thread is difficult. A system needs a lot of control to be stable. Giving control away risks instability because interrupt and other core functions are not negotiable. Threads are also very difficult yet easy to abuse. What specific user space parallel IPC programming model is interesting? There are many? What object reuse policy is expected? On Mon, Oct 20, 2014 at 2:36 PM, Kevin Elphinstone < [email protected]> wrote: > “supports” is too strong a word J > > > > We have some internal research prototypes we use for exploring the > research challenge of concurrency versus verification tractability, in > addition to currency models for microkernels in general. Some of that code > is probably what you have found. The code is likely to be highly > experimental, and not what we are actively working on. > > > > We have more mature research prototypes (still prototypes) internally that > we a working towards releasing when time allows. I can’t give an accurate > estimate, but it is likely to be in terms of weeks, not months. > > > > - Kevin > > > > *From:* Devel [mailto:[email protected]] *On Behalf Of *Yuxin Ren > *Sent:* Tuesday, 21 October 2014 1:05 AM > *To:* [email protected] > *Subject:* [seL4] sel4 on multi-core > > > > Hi All, > > > > I think, on IA-32, sel4 supports multi-core machine. > > But I do not how to use that. Here I have two specfic questions. > > 1. How to assign a specific core to a process/thread? And can I change > this affinity? > > > > 2. How to two process/threads communicate via IPC on different cores? > > I want to know some implementation details in kernel to support cross-core > IPC. > > Could anyone explain its logic or tell me the code for it in the kernel? > > > > Thank you very much. > > Best, > > Yuxin > > ------------------------------ > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its attachments. > > _______________________________________________ > Devel mailing list > [email protected] > https://sel4.systems/lists/listinfo/devel > > -- T o m M i t c h e l l
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
