Re: shared dataspace for l4re_kernel/ registering additional caps in ned

Adam Lackorzynski <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <[email protected]>
On Sat Sep 20, 2014 at 20:45:19 +0000, Stark, Josef wrote:
> Everything's working so far! But I have another question... (the actual question is at the bottom)
> 
> Here's what I do now:
> If manager wants to start a received binary, it tells Ned to start "network",
> e.g. start({caps = {ipc_gate= L4.Env.ipc_gate}},"network"); and Ned then starts
> - as usual - l4re. l4re then detects the special filename - "network" - and instead of 
> trying to load a file with this filename from ROM (which doesn't exist) it asks manager for 
> the shared dataspace which holds the binary. Since manager may alter the content
> of the shared dataspace later, l4re copies the shared dataspace and then launches this copy.
> 
> So, basically, (in main.cc of l4re_kernel) instead of 
> 
> 	file = L4Re_app_model::open_file(Global::l4re_aux->binary);
> 
> we do
> 
> 	L4::Cap<L4Re::Dataspace> ds;
> 	get_shared_dataspace(ds); //allocation and IPC stuff
> 	file=L4Re_app_model::alloc_ds(ds->size()); //this method is now static
> 	L4Re_app_model::copy_ds(file,0,ds,0,ds->size());
> 
> and then continue with the regular 
> 
> 	loader.start(file, Global::local_rm, Global::l4re_aux);
> 
> which works.
> 
> 
> But my question is, once the task gets killed or finishes, do I need to release/free/unmap
> the dataspace "file" again (since it is a copy in memory and not a file on ROM)
> to avoid a resource leak, and, if so, where whould I do this? Or is this done automatically?

This will be done automatically. Moe will free resources when all
clients are gone.



Adam
-- 
Adam                 [email protected]
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.