On Tue Oct 04, 2011 at 10:29:11 +0200, François Goichon wrote:
I have some questions regarding object-capabilities and physical memory mapping.
- First of all, my goal is to manage and develop drivers on top of
Fiasco. The documentation mentions the existence of an I/O server that does not seem to be on the repository anymore. Did I miss any announcement or is the I/O server in development?
It's there at l4/pkg/io
- As I did not find this server, I tried to code drivers from
scratch but fail to see how I can map physical addresses in the first place. With other L4 kernels I would expect to find a map system call which would provide such a mapping to a thread with sufficient capabilities. In your model however, it seems that object-capabilities on such operations are transmitted to sigma0 only and that further mapping requests should go through sigma0. I actually lack any example on how to talk to sigma0 in the first place - what OC should I use as the first argument of l4sigma0_map_iomem().
You give it the cap to sigma0, but I won't go further, it's not supposed to be used by apps.
- I also fail to understand the actual meaning of the environment
OCs "map region" and "mem alloc" and the actual operations they provide, along with the "classic capabilities" my thread has on physical addresses for instance. Moreover, is there any configuration step where I can modify/list those "classic capabilities" passed to the thread spawned by moe?
Ned is the component that loads programs and sets up their initial environment, including caps. You cannot list them, but you do know them because they are specified in the loader script. Programs generally do not know anything about physical addresses or memory. The memory allocator provides you with memory in the form of dataspaces. Those dataspaces can be mapped into an address space. For device iomem io also provides a dataspace that gives you access to the mmio region of the devices the app is assigned to.
Adam