[okl4-developer] Question about memsection_create_fixed, iguana server library

[Nelson Tam]

Hi Anand,

On 15/04/2008, at 11:32 AM, Anand Gore wrote:
>
> The thing is that I want to make it a "dynamic" loading as much as
> possible. That's why I want to create that memory section on the fly  
> and
> load this pre-built binary into the known location. In fact, I didn't
> really want to fix the virtual address, instead if I could just  
> create a
> memory section at run time and dynamically translate and load this
> binary into the allocated memory section. But I wasn't sure if that  
> was
> possible. Do you think that is achievable and if so how to do it?

In the method I've described in the previous email, the virtual  
address is not fixed, in the sense that we did not specify the virtual  
address explicitly.  However it is most likely to be determinate (it  
will be the same on every bootup).

As for translating and loading the binary during runtime, that is  
certainly achievable.  It is not implemented in the 2.1 release yet,  
but it is part of our upcoming roadmap.

The virtual and physical memory allocation framework is already in  
place, in the way that I've outlined in the previous email.  Also  
please take a look at the Elfweaver manual (now available at http://portal.ok-labs.com 
) for more details.

Another part of the challenge would be accessing the binary contents,  
which would almost certainly involve a device driver if it is not  
already in memory.

Then you will need to write or port a binary interpreter and loader on  
OKL4.

> Another question about the physical section, this address space is not
> virtual adress space? So is it that it's mapped 1 to 1 with the  
> virtual
> adress (0x2000000) and is shared between different tasks?

The physical section is not shared between different protection  
domains, or PDs (what you referred to as 'tasks').  It is mapped  
contiguously with virtual memory, but not 1-to-1.  In other words the  
physical base (0x2000000) could be mapped to a different virtual base  
(say 0x80000000), but a simple offset is all you need to translate  
between the paddr and vaddr.

> Is this a good idea, to create a memory section and loading an
> executable binary and jumping to the entry point of it in a separate
> thread? Or there is a better alternative than that. We need to share  
> the
> memory space between the current thread and the binary which will
> eventually be running into this new space.

That is a possible approach.  Creating the execution thread in the  
same PD as the loader thread would achieve what you've described.

> Also do you know, when the documentation of the elfweaver be  
> released to
> the public, if it will be?


http://portal.ok-labs.com, fresh out of the works!

--
(nt)

Nelson Tam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1560 bytes
Desc: not available
Url : http://lists.okl4.org/pipermail/developer/attachments/20080418/46c39305/attachment.bin