Share a variable of Core with other components
Jaemin Park
jmpark81 at ...9...
Fri Feb 2 13:49:58 CET 2018
Hi,
I really appreciate your kind and quick response.
In my case, a one-way read-only fashion is enough.
I'd like to share an information that other components can read only.
If you can give me an example or any reference code published in the git
repository, please let me know.
Sorry for a newbie's request.
JaeminPark
On Fri, Feb 2, 2018 at 6:27 PM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:
> Hi Jaemin,
>
> On Fri, Feb 02, 2018 at 11:28:53AM +0900, Jaemin Park wrote:
> > Hi,
> >
> > I'd like to ask a question about a way to "share a variable of Core with
> > other components".
> >
> > I'm using i.MX53 QSB, so this question is based on 'base-hw'
> implementation.
> >
> > Suppose that 'Core' has a variable "A" and makes it visible to other
> > components like 'Init' or else.
> >
> > For this, I added a routine to use a Dataspace_capability for "A" in
> main()
> > of 'Core' as follows:
> > *[repos/base/src/core/main.cc]*
> > *Dataspace_capability ds = env()->ram_session()->alloc(4096);*
> > *unsigned char *local_addr = env()->rm_session()->attach(ds);*
> >
> > However, I faced a difficulty to implement an RPC to delegate(share) the
> > Dataspace_capability to other components.
> >
> > Is there any simple or proper way to share "A" of 'Core' with other
> > components?
> > If possible, please give me an example.
>
> Well, in general there are only few examples where core 'shares'
> memory with other components. Due to core being the security critical
> kernel component, it is a bad idea to widen the interface to it too
> much. Apart from this disclaimer, there are some information needed to
> be exported from core to specific components, e.g., platform
> information like ACPI etc. from the booting infrastructure exported to
> the platform driver. Those information are shared in a one-way
> read-only fashion. Therefore, it is enough to create a dataspace
> within core, and export it as a ROM module using a dedicated name for
> it. The user-level component can open that dataspace using the normal
> ROM session interface of core.
>
> If you want to share information bi-directional this approach
> obviously is no way. On the other hand it is not recommended at all to
> import data into the kernel beyond the existing system calls.
> An exception is the VM session interface of base-hw's core, which
> exports a dataspace to the VMM component used to reflect the machine
> register set of the VM under control of the VMM. Those register
> contents can be altered by the VMM, e.g., after doing some device
> emulation, and is taken by the kernel to reload the registers when
> switching to the VM again. Of course, when sharing data in such a way
> both sides need to synchronize before accessing the shared data.
> Because core/kernel cannot block on any user-level component, signals
> are used to hint the VMM about a change of the VM state, whereby the
> VMM calls core via IPC (VM session interface) to mark that the VM
> state handling has finished, and the VM is re-runnable.
>
> I hope this clarifies your question. If not you may explain your
> use-case in more details.
>
> Best regards
> Stefan
>
> >
> > Any comment comments would be highly appreciated.
> >
> > JaeminPark
>
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> > _______________________________________________
> > genode-main mailing list
> > genode-main at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/genode-main
>
>
> --
> Stefan Kalkowski
> Genode labs
>
> https://github.com.skalk | https://genode.org
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180202/166d2929/attachment.html>
More information about the users
mailing list