Separating Architecture Specific Code

[AJ]

Hello,

As I'm implementing this at the moment, I nearly put it in the OS Development forum, but I'm not talking code, so went for this one...

I am trying to separate out the architecture dependent part of my OS from the architecture independent stuff - much in the same way as Linux has an /arch directory. At the moment, I am just at the 'planning' stage of this but have ended up with this kind of list (certainly not exhaustive!):

Architecture Dependent (must be rewritten for each arch):
* Memory Management (but looking through Linux source, a lot of mm seems to be in the main source tree outside /arch)
* Interrupt Handling <-- this leads me to think that almost the entire scheduler must be in the architecture dependent portion???
* System Call interface (can then call code in the architecture independent section).
* Device detection code (but driver interface is arch dependent).

Architecture Independent:
* VFS
* Driver Interface
* Executable Relocator (but the part that prepares a new process for execution must be arch dependent).
* All the higher level stuff such as window manager, apps and so on.

I guess more will come to light as I start implementing things. The problem for me at the moment is that firstly, the line between what should be in /arch and what should not seems a little blurred at present. This is especially the case when there is something I think of as one 'unit', such as the MM, which may be split between '/arch' and the rest of the source tree.

Also, given the lists above, it looks like there is a hell of a lot of stuff to go in the /arch directories.

I'm going to start off by implementing an x86 port for an x86_64 kernel.

All thoughts / hints appreciated!

Cheers,
Adam

[jvff]

Not much experience in the area, but in theory you can isolate the algorithm from the implementation details. This way most of the stuff is architecture independent, leaving crude details specific to each architecture separated. This is similar to an exokernel design. For example, the scheduling algorithm is hardware independent, but the way you configure the timers isn't. Memory managing algorithms are independent, but the way you set it up isn't. Anyway, this is in theory. Hope it helps,

JVFF

[xyzzy]

Hey!

I haven't actually ported my kernel to other archs yet, but I'm trying to keep the source seperated so it'll be easy to port when I want to.

* Memory Management (but looking through Linux source, a lot of mm seems to be in the main source tree outside /arch)

Most of my memory management is arch-independent. The main arch-specific portion of it is paging - for me, each arch should provide a set of functions (with the same name over all archs) for mapping/unmapping pages into an address space. That way, my virtual memory manager can all be in arch-independent, and just call those functions to do certain things. The pagefault handler collects information the VMM needs and calls it's pagefault function, which is also arch-independent. I also have some defines in an arch header which define stuff like page size, where user memory starts and where it ends, etc.

The other arch-dependent part is setting up the physical memory manager. For i386, it just gets the size of the physical memory from the multiboot info and passes it to pmm_init. By using the defines mentioned above, and the information it gets passed, the PMM can remain arch-independent too.

* Interrupt Handling <-- this leads me to think that almost the entire scheduler must be in the architecture dependent portion???

The actual interrupt handling code is arch-specific, yes, but this doesn't mean you have to put the scheduler there. Task switching is arch-dependent, and for this I have a small bit of code in the arch folder which handles setting up a stack for the process, stack switching, etc. The scheduler is arch-independent, and the timer handler just calls a function in the scheduler to decrease the timeslice of the current thread. On every interrupt a function is called to check if the thread should be preempted.

* System Call interface (can then call code in the architecture independent section).

Yes, this is arch dependent, but it's fairly small and you can just have it call your system call functions.

* Executable Relocator (but the part that prepares a new process for execution must be arch dependent).

This possibly depends on the executable format. ELF has some stuff that depends on the architecture you're running on so it is probably better to put this under arch-dependent. The code to switch to userspace is definitely arch dependent though.

I guess more will come to light as I start implementing things. The problem for me at the moment is that firstly, the line between what should be in /arch and what should not seems a little blurred at present. This is especially the case when there is something I think of as one 'unit', such as the MM, which may be split between '/arch' and the rest of the source tree.

As I've mentioned above, process management and memory management can all be split between arch-dependent and arch-independent. A good way to go about it is to make each arch provide a set of functions that all do the same thing (as far as the arch-independent code is concerned), that the rest of the code can use. If you're in doubt about where something should go, ask

Hope that helps,
Alex

[AJ]

Thanks for your thoughts on this. I'm gradually going to start the implementation over the next few days.

Interesting thing I've just seen about the paging in the linux source - it seems to provide a software MMU for archs that do not have a hardware one, so that the /arch bit still looks the same...cunning

Cheers,
Adam

[AndrewAPrice]

* Executable Relocator (but the part that prepares a new process for execution must be arch dependent).

This possibly depends on the executable format. ELF has some stuff that depends on the architecture you're running on so it is probably better to put this under arch-dependent. The code to switch to userspace is definitely arch dependent though.

Make all your end applications arch-independent by compiling your code into bytecode and use JIT compiling.

[AJ]

I would love to do that, but as I know nothing about it, need to do a lot of research.

My first aims are to get Newlib and standard C++ support up and running. Once I can do that, I'll look in to bytecode in more depth. I really quite like C# as an apps programming language and investigated it recently. I was a little disappointed about how much seems to be proprietary and am a little concerned about how M$-ified it is - not wanting to infringe on any patents.

Anyway - JIT compiling still remains high up the priority list on my 'long-term goals'.

Cheers,
Adam

[AndrewAPrice]

You can have a look at Mono for an open-sourced .Net implementation.