shared memory Beispiel?

Adam Lackorzynski adam at
Fri Sep 2 00:44:45 CEST 2005

On Thu Sep 01, 2005 at 19:48:33 +0200, Mathias Krause wrote:
> Adam Lackorzynski wrote:
> >>To map it into L4Linux 2.6, you have to reserve a range of virtual memory
> >>inside the Linux server (Adam, which function should someone use for this?)
> >>and then map it into that reserved region via l4dm_map_ds() (see dm_phys
> >>manual). Since L4Linux 2.6 makes havy use of L4env functionality, this
> >>function is available. Make sure that the whole dataspace is mapped into
> >>L4Linux since there is no region manager.
> > 
> > The Linux server is a 'normal' L4Env application so mapping memory
> > works as usual. Depending on what one wants to do it may be necessary to
> > make the memory region known to Linux. But if it's (just) a driver one
> > can simply use it.
> So a l4rm_attach() in L4Linux is just fine? No conflicts with virtual 
> addresses?

The RM is there to avoid this.

> Currently I do a l4dm_mem_open() plus l4dm_share() in the driver task 
> followed by a l4rm_attach() on this dataspace in L4Linux. But I fear 
> that the mapped virtual address range maybe get accidentally reused by 
> L4Linux?

No, L4Linux is an L4Env app and those make sure they properly register
the regions they use.

> So my question is if I need to inform L4Linux about my mapping 
> or if the region mapper just handles this fine?
> If I need to could you please tell me how I should do this?

l4rm_attach is ok.

>  > Look at the stub drivers in 2.6, they just do that.
> Neither the oshkosh nor the l4or driver stub make use of the functions I 
> mentioned? Maybe I do something wrong? :/

Those functions are in the client libs so that they're hidden (and
besides the client libs know nothing about Linux). The frame buffer
driver maps some memory itself so that may be a better example.

Adam                 adam at

More information about the l4-hackers mailing list