All,
I accidentally responded off list to this topic. Here's Adam's reply that may be helpful to others with similar questions to this thread. Adam's suggestion on where to look for example code and other comments are below. I was able to use the example code to create two linux apps, one which creates a DS and another that attaches to that DS.
Julian
-------- Original Message -------- Subject: Re: l4dm_mem_open call from L4Linux user process Date: Thu, 29 Sep 2005 22:05:18 +0200 From: Adam Lackorzynski adam@os.inf.tu-dresden.de To: Julian Grizzard grizzard@ece.gatech.edu References: 433ABD93.2020303@ece.gatech.edu 20050929074724.GL31351@os.inf.tu-dresden.de 433C3AE5.4070601@ece.gatech.edu
On Thu Sep 29, 2005 at 15:05:09 -0400, Julian Grizzard wrote:
Adam Lackorzynski wrote:
Hi,
On Wed Sep 28, 2005 at 11:58:11 -0400, Julian Grizzard wrote:
I've been working with the dataspace calls with the L4Env running x86 Fiasco. I am trying to create a dataspace from a L4Linux user process, but I am having trouble getting the program to compile. Is my Makefile correct for what I am trying to do? Is there any reason I shouldn't be able to link to l4dm_mem_open from a L4Linux user process? Below is my source, Makefile, and compiler error message. Help much appreciated!
Umm, basically it's possible to create a new DS in an L4Linux user app, as it is created at your DS manager (so most likely dm_phys). This has nothing to do with L4Linux or the user app in the first place. Attaching to it is a different issue altogether!
Alright, so my eventual goal would be to attach to the DS as well. So, attaching to a DS is going to be a problem? I figured I would try a simple case first: just create the DS.
The address space of a Linux user app is handled by the Linux server, so if one starts mapping stuff in there without telling Linux it may just overmap this area as it believes it is free, or in other words, no one is mapping stuff in there (which cannot happen in native Linux, so this is ok). So now one could start telling Linux about that region. I think the cleanest way would be to hack something in L4Linux to exclude/reserve a region in an address space of a task. This has not been done yet. Something cheaper could be to mmap something and then overmap it itself, or similar. Depending on what you want to do, there's a good example in l4/pkg/loader/examples/fprov-l4/main.c where a DS is opened but the attaching is done in a way that it works, i.e. some memory in BSS is allocated and unmap, and then, at this location, a page from the DS is mapped in. Just have a look, maybe this is ok for you.
---------- SOURCE ---------- #include <l4/dm_mem/dm_mem.h> #include <l4/l4rm/l4rm.h>
#include <l4/sys/types.h> #include <l4/dm_generic/types.h>
int main(int argc, char**argv){ l4dm_dataspace_t ds; void *addr;
l4dm_mem_open(L4DM_DEFAULT_DSM,8192,0,0,"L4RM example",&ds); printf("hi\n");
return 0; }
---------- MAKEFILE ---------- PKGDIR ?= ../.. L4DIR ?= $(PKGDIR)/../..
TARGET = $(PKGNAME)
MODE = host
Mode 'host' has no L4 specific libs, includes etc, try 'l4linux' which gives you host + L4 stuff.
This should basically fix your linking problem because the libs you link have dependencies to other libs which must be fulfilled.
Okay, I've tried mode = l4linux. Now I get the error message below. Looks like some libraries are still not getting pulled in. Do I need to manually specify some L4LIBS? I tried several combinations but didn't get anywhere. Any ideas?
Whoa, looks like this was the wrong approach. This is pulling much more in which is really too low level for a Linux program. But have a look at the fprov-l4 example, it is hopefully enough for what you want to do.
Cheers, Adam