l4dm_mem_open call from L4Linux user process

Julian Grizzard grizzard at ece.gatech.edu
Wed Oct 5 02:41:53 CEST 2005


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.


-------- 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 at os.inf.tu-dresden.de>
To: 	Julian Grizzard <grizzard at ece.gatech.edu>
References: 	<433ABD93.2020303 at ece.gatech.edu> 
<20050929074724.GL31351 at os.inf.tu-dresden.de> 
<433C3AE5.4070601 at 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)/../..
> >>
> >>
> >>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.

Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

More information about the l4-hackers mailing list