Hi Mathias,
please send questions like this to l4-hackers in every case. Simply because I'm not the only one with knowledge about L4/L4-Userland. The other reason is that other L4 developers might be interested in such questions as well.
On Wednesday 31 August 2005 10:03, you wrote:
ich versuche eine L4-Anwendung zu schreiben, die mit shared memory arbeitet. Konkret soll ein Kernel-Thread in L4Linux-2.6 (ein Netzwerktreiber-Stub) über den gemeinsamen Speicher mit einem L4-Task (der ausgelagerte Netzwerktreiber) die zu sendenden, bzw. empfangenen Rahmen austauschen. Ich hab schon im l4/pkg-Verzeichnis nach etwas passendem gesucht, doch bin nicht wirklich fündig geworden, wie man dass nun am Besten macht. Ich will ja nur ein Stück Speicher fester Größe read/write für zwei L4-Threads mappen. Muss ich dazu den Dataspacemanager benutzen, oder den Regionmapper, oder gar l4io? Oder geht das vielleicht doch allein mit den L4.V2-Systemrufen?
I would suggest to use the dataspace manager dm_phys to allocate some memory and to map it into both L4Linux 2.6 and the native L4 task. Mapping into the native L4 task should be no problem as long this task has a region manager (the normal case for L4env tasks) -- simply attach the dataspace to the region manager.
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.
Finally, make sure that both tasks have the right to map the dataspace. If the Linux server creates the dataspace it has to share the rights explicitly with the native L4 task with l4dm_share().
A more advanced approach would be to use the DSI (DROPS streaming interface) which is also available at the remote CVS. The DSI provides functions for synchronization between clients accessing the same dataspace. There is the dsi_example package.
There might be comments from other people reading this list.
Entschuldige, dass ich Dich mit solch banalen Problemen störe, doch ich weiß eben nicht, wie man das macht und die Dokumentationen (dm_mem, dm_phys, L4-Referenzmanual, ...) sind dahingehend nicht gerade aussagekräftig :/
IMHO there still were some threads about this on l4-hackers (please see http://os.inf.tu-dresden.de/mailman/listinfo/)
Frank
On Wed Aug 31, 2005 at 10:36:19 +0200, Frank Mehnert 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. Look at the stub drivers in 2.6, they just do that.
Adam
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? 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? 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?
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? :/
Greets, Mathias
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
l4-hackers@os.inf.tu-dresden.de