I have become quite familar with L4/x86 Reference manual and L4 User manual (for MIPS) but I think they don't give enough information about designing and writing programs on to the L4 architecture. In my opinion they are a bit unclear and incomplete. Therefore I'd like to ask some questions on that subject.
What kind of address space do the initial servers get? I know that sigma0 has the complete physical address space idempotently mapped but what about others? What pages do they have initially mapped?
I have understood that the kernel isn't able to free memory it has allocated. Is that true?
How is the destination address of an intercepted IPC delivered to the chief?
What is sigma1? What should it do?
Is sigma0 able to map memory above 0x40000000? How?
What happens when the version numbers of a task are used up? Could they be reused?
Could tasks donate interrupts like they can donate task numbers?
Thanks for everyone who bothers to answer.
"Js" == Juho stman jostman@myrealbox.com writes:
Js> I have become quite familar with L4/x86 Reference manual and L4 User Js> manual (for MIPS) but I think they don't give enough information Js> about designing and writing programs on to the L4 architecture. In Js> my opinion they are a bit unclear and incomplete.
Fair statement. These docs tend to be created on demand...
Feel free to add to the UM :-)
Js> Therefore I'd like to ask some questions on that subject.
Js> What kind of address space do the initial servers get? I know that Js> sigma0 has the complete physical address space idempotently mapped Js> but what about others? What pages do they have initially mapped?
Nothing -- like any new task they start off with an empty address space. They have sigma0 as their pager, which will respond to page faults within the RAM area by mapping the corresponding pages idempotendly, unless the page is already mapped to someone else (that's essentially sigma0's paging protocol). Hence it is important to link initial servers such that their code and data is allocated at non-overlapping virtual addresses within sigma0's address space.
Js> I have understood that the kernel isn't able to free memory Js> it has allocated. Js> Is that true?
Depends what you mean. The kernel cannot (in the present version) reclaim memory it kernel has allocated to sigma0, and sigma0 won't return it voluntarily. Nor will the kernel release to sigma0 any of the "reserved" RAM. (But that's really a sigma0 protocol issue, and you could use a separate sigma0 which behaves differently. But the present kernels won't be able to make use of that.)
If your question refers to memory allocated to kernel data structures (TCBs and page tables) within the kernel reserved memory regions, there is no reason the kernel cannot reclaim that (e.g. when a task is deactivated).
Js> How is the destination address of an intercepted IPC Js> delivered to the chief?
The kernel leaves the destination address specified by the sender in the original registers and (a4 on MIPS, ESI/EDI on x86) and thus delivers the intended destination to the chief. There are C bindings (e.g. *_ipc_chief_receive) which return that ID to the caller.
This is not explained in the UM because it was not implemented on the MIPS at the time the manual was written. Should be added some time...
Js> What is sigma1? What should it do?
Supposed to be the kernel's pager (e.g. for demand paging page tables). Not supported on any present implementation.
Js> Is sigma0 able to map memory above 0x40000000? How?
Sigma0 will only map the physical memory range (and pages used for accessing memory-mapped devices).
Js> What happens when the version numbers of a task are used Js> up? Could they be reused?
Present kernels will probably either panic or let the task_new() call fail. There is an API revision on the cards which will provide a better solution eventually.
Js> Could tasks donate interrupts like they can donate task Js> numbers?
Good point! This is actually a proposed API change which will probably come in one form or other :-)
Js> Thanks for everyone who bothers to answer.
No worries.
Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5533 _,--._* Sydney, Australia 2052 E-mail: gernot@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F
Js> I have understood that the kernel isn't able to free memory Js> it has allocated. Js> Is that true?
Depends what you mean. The kernel cannot (in the present version) reclaim memory it kernel has allocated to sigma0, and sigma0 won't return it voluntarily. Nor will the kernel release to sigma0 any of the "reserved" RAM. (But that's really a sigma0 protocol issue, and you could use a separate sigma0 which behaves differently. But the present kernels won't be able to make use of that.)
If your question refers to memory allocated to kernel data structures (TCBs and page tables) within the kernel reserved memory regions, there is no reason the kernel cannot reclaim that (e.g. when a task is deactivated).
What about the case when the kernel would need more memory for page tables and the initial servers have already allocated all memory from sigma0?
"J=" == Juho =?iso-8859-1?Q?=D6stman?= <Juho> writes:
Js> I have understood that the kernel isn't able to free memory Js> it has allocated. Js> Is that true?
Depends what you mean. The kernel cannot (in the present version) reclaim memory it kernel has allocated to sigma0, and sigma0 won't return it voluntarily. Nor will the kernel release to sigma0 any of the "reserved" RAM. (But that's really a sigma0 protocol issue, and you could use a separate sigma0 which behaves differently. But the present kernels won't be able to make use of that.)
If your question refers to memory allocated to kernel data structures (TCBs and page tables) within the kernel reserved memory regions, there is no reason the kernel cannot reclaim that (e.g. when a task is deactivated).
J=> What about the case when the kernel would need more memory for page tables J=> and the J=> initial servers have already allocated all memory from sigma0?
At the present time the kernel will have the choice between panicking or shooting down tasks.
There's a paper by Jochen in a recent HotOS suggesting a way the kernel could reclaim memory from apps.
Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5533 _,--._* Sydney, Australia 2052 E-mail: gernot@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F
At the present time the kernel will have the choice between panicking or shooting down tasks.
There's a paper by Jochen in a recent HotOS suggesting a way the kernel could reclaim memory from apps.
Cristan has been working on a proposal for non-persistant mappings. Ie when you run out of memory you dump some mappings and free the memory they use. You'd have to ask Cris about the state of his proposal but he's been exploring the idea. The idea is that the kernel would flush a mapping and then a standard page fault would occur and your pager would map it back if required. Of course we have been discusing pinning of mappings and non-policy bound mecanisms for doing this.
cheers Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam 'WeirdArms' Wiggins -
Gernot Heiser -
Juho Östman -
Juho �stman