RTEMS in Pok analysis questions
claudiodcsilva at gmail.com
Wed May 30 18:03:26 UTC 2012
I beleive that an RTEMS partition running on top of POK should be a
black box from POK's perspective. The configuration of the RTEMS'
tasks are a matter for the RTEMS' configuration and not for POK's
configuration. Additionally the partition shall be exclusive to RTEMS,
so no POK native tasks should be allowed in that particular partition
(at least for now...).
I think the context switch in the RTEMS-partition will have to be
implemented through a POK system call. This should also be true for
other hypervisors, therefore this "access point" shall be abstracted.
On Wed, May 30, 2012 at 6:38 PM, WL <jolkaczad at gmail.com> wrote:
> RTEMS task states not match Pok's (and it should be assumed they will
> not match othet hypervisors') and also Pok needs tasks assigned at
> compilation time whereas RTEMS allows an unlimited number of objects
> (including tasks) created at runtime. It seems that the context
> switching should be implemented in the BSP, but from Pok's perspective
> isn't it unsafe to allow a guest partition to modify the processor's
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel