> On 1 Sep 2015, at 10:06 am, Raymond Jennings <[email protected]> wrote: > > Hey, quick question. > > This is just hypothetical, but would making management of > pagetables/pagedirectories a low level literal operation hurt seL4's > portability to other architectures that might not even use page tables? > > I could be mistaken but I think there's some archs out there that only have > software TLBs (openrisc IIRC among them) > > Please forgive me if I'm mistaken but my recent question about memory > abstraction reminded me about this.
Yes, there’s no attempt to provide abstraction for this, different architectures have different memory management mechanisms and seL4 will provide different APIs for them — they are in the arch-dependent part of the kernel. The currently supported architectures all happen to have page table structures, but we had an initial MIPS-like seL4 version with a software-loaded TCB that exposed a different API (reusing the CNode concept for virtual memory), and PPC would probably be different again. The rationale is that abstracting memory management too early can severely hurt performance. Such abstractions should be provided at higher layers of the system software. It doesn’t make porting seL4 harder (it would actually be harder to expose the same interface for all possibly MMU designs), but it does mean that the systems software on the next level up needs to know which architecture it is running on, which it should anyway if it wants to make use of the hardware efficiently. Cheers, Gerwin ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
