[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hurd-l4 VM server
Re: hurd-l4 VM server
07 Apr 2003 15:24:37 +0200
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
>>>>> "Marcus" == Marcus Brinkmann <address@hidden> writes:
Marcus> Interesting, as a first cut at having virtual memory at
Marcus> all :)
for now I'm testing the pmap.c port (where I've substituted native use of MMU
with l4/ipc sigma0 calls) and fixing it where wrong
Marcus> Do you know about Neal's user space virtual memory
Marcus> management ideas?
I've read it and also studied for a long time Cranor dissertion about uvm. So
I think uvm external interface provide feature described by Neal's except
memory container structure (which exists but must be fixed to work in
user-space). I'll try as first test to write down an idl interface which is
a uvm 1-1 map + an external structure which will act as memory container
and then see what's come out.
>> * I'm thinking (and this is my question) which interface VM
>> server should have in order to be contacted and used from other
>> HURD (and others) servers. Should I "simply" code an IDL
>> interface mapping it 1-1 with uvm_extern.h or you can suggest
>> something better?
Marcus> Well, Neals paper contain some suggestions about how such
Marcus> an interface should look like, but it is a completely
Marcus> different design. For a monolithical vm server based on
Marcus> uvm, something like the current interface we have in Mach
Marcus> is probably appropriate and blends in best with the code
Marcus> base we have. Note that user space paging is an essential
Marcus> feature in the Hurd.
in fact uvm is an evolution of mach vm. Many actual OS' vm are
mach2.5 derived from. As you can read in Cranor dissertion page 18.
So could be fine to have an interface similar to mach vm (as first version,
in future i don't know...)
mach2.5 vm -> uvm -> GNU VMM (user space)
Marcus> There are some issues with the interface, in particular
Marcus> vm_map, which concern us, though. It would be nice to be
Marcus> able to map from several objects atomically. You should
Marcus> be able to find details in the hurd-devel archives,
Marcus> althoguh I am not sure. I could dig them out from my
Marcus> folders otherwise.
Isn't necessary I'm looking at them in hurd and mach sources (also glibc in
order to see how c memory functions work with mach) also in OSF mach docs.
Marcus> Thanks, Marcus
Thank you for details,
Maurizio Boriani -- Networking staff
GPG key: 0xCC0FBF8F
fingerprint => E429 A37C 5259 763C 9DEE FC8B 5D61 C796 CC0F BF8F <= fingerprint