Portability: Difference between revisions

1,073 bytes added ,  1 month ago
m
Reverted edits by Strokegmd (talk) to last revision by Khaledhammouda
[unchecked revision][unchecked revision]
(PLEASE Expand on this, I was surprised we didn't have one)
 
m (Reverted edits by Strokegmd (talk) to last revision by Khaledhammouda)
 
(11 intermediate revisions by 8 users not shown)
Line 6:
=== Prep Work ===
C and C++ code can be crossed compiled onto many systems, so chances are if you can target gcc to run on it, you can write a kernel for it. Some hardware will be easier and more thoroughly documented than others, but in any case, you should fully understand the system in which you're developing for, and read all it's manuals and specifications. Once you feel confident with it, you can begin.
 
=== Separate Sources ===
Your kernel will have functions that contain what is called '''generic''' and '''targeted''' code. For example: a puts() implementation will be generic, while the screen driver that puts() uses to draw the string to the output device would be targeted to a specific implementation. Before you begin trying to code for more than one platform, separate your sources so any targeted functions are in a different location than generics. This creates an abstraction layer between hardware drivers and pure software. The NT kernel has a subsystem for this called HAL (Hardware Abstraction Layer) thatThat way, all you need to do to port your kernel to a new platform is re-write the targeted functions for the platform, and the generic code can run on top of it.
 
=== Code! ===
Targeted code can be further divided into two categories: architecture-specific code and machine-specific code. Architecture-specific code is code that differs between different processor architectures, like I/O, trap dispatching, and paging. Machine-specific code is code that differs between machines with the same processor architectures, like IRQ controllers, system timers, real time clocks, and multiprocessor information. The NT kernel has a module containing machine-specific code called the Hardware Abstraction Layer, or HAL.
 
=== Code! ===
After the targeted files are separated, you can make new targeted functions for each platform you want to port to. The generic code will (usually) run without issue on top of the targeted code. A brief side note, make sure to delete the object files after you re-target, as object files are not cross compatible.
 
=== Next Steps ===
Once your architecture-specific code has been separated, you need to begin writing drivers for the new platform. Even though you've modified your kernel to be able to run on top of any hardware, you still need to write the drivers that have code specific to your platform. For example, if you had an x86-only kernel before, and you separated out the targeted code and wrote targeted code for the Raspi, in order for your OS to actually interface with the user, you have to write device drivers for hardware like the screen and audio controllers.
 
== Example Targeted Functions ==
* init functionsBooting (usually assembly stubs)
* CPU Specific functions (IDTI/O, GDTTrap Dispatching, UsermodePaging, switchingContext Switching, codeSMP)
* Timers (PIT, RTC, APIC Timer, HPET)
* Hardware Component Drivers (PS/2, Serial, VGA, Sound, PIT, RTC)
 
== Example Generic Functions ==
Line 21 ⟶ 28:
* String parsing functions
* Buffered I/O (gets, putchar, etc)
 
[[Category:Porting]]
[[Category:OS theory]]
[[Category:FAQ]]