The wiki is very x86-centric, however I feel that there should be a page about the theory behind making a kernel portable (or, in a grander scheme, an OS). As I am personally going through the process porting my kernel to PPC, I thought I should make this page:
http://wiki.osdev.org/Portability
It is no where near complete, I just threw together a base. Feel free to discuss and add to it as the community sees fit.
Personally, I think that a portable kernel should be a design feature present on all kernels, if not just because it keeps your source tree cleaner.
--Primis
Portability
Re: Portability
Good idea. Should help people avoid the nightmare of adding portability at a late stage!
Cheers,
Adam
Cheers,
Adam
Re: Portability
I used Linux (and probably other kernel) way that I have directory arch but however I see need for list which arch have which component.
For example paging/MMU may be differently implemented but kernel can have one way how to count free pages despite that they are 4KB or 4KB and 4MB or ....
For example paging/MMU may be differently implemented but kernel can have one way how to count free pages despite that they are 4KB or 4KB and 4MB or ....
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Portability
For things that might change like what bootloader you use or what architecture you are on I build libraries for those so I have mboot.a for multiboot-compliant bootloaders and stuff like libarm.a or libx86.a for architectures. Then I just pick and choose what components I want during linktime.
Fudge - Simplicity, clarity and speed.
http://github.com/Jezze/fudge/
http://github.com/Jezze/fudge/
- Marionumber1
- Member
- Posts: 56
- Joined: Sun May 08, 2011 9:03 am
Re: Portability
Good start, but I have a few suggestions. My first thing is minor, but in Windows NT, the HAL doesn't handle all architecture specific code. The HAL only handles differences between hardware on the same CPU architecture (like 8259 PIC vs APIC, uniprocessor or multiprocessor, whether ACPI is supported). Architecture specific code (like GDT and IDT on x86, Paging) is part of the kernel. Also, I would disagree that drivers are targeted code. Architecture specific code should only contain what the kernel needs to initialize itself.
Programmer and security enthusiast
DarkSide OS Kernel
Those who do not understand Windows NT are doomed to criticize it, poorly.
DarkSide OS Kernel
Those who do not understand Windows NT are doomed to criticize it, poorly.
- Primis
- Member
- Posts: 62
- Joined: Fri May 14, 2010 3:46 pm
- Libera.chat IRC: Primis
- Location: New York, NY
- Contact:
Re: Portability
I wouldn't call myself an expert on portability or kernels, I just like taking initiative. If you want, feel free to modify the article, it is a wiki after allMarionumber1 wrote:Good start, but I have a few suggestions. My first thing is minor, but in Windows NT, the HAL doesn't handle all architecture specific code. The HAL only handles differences between hardware on the same CPU architecture (like 8259 PIC vs APIC, uniprocessor or multiprocessor, whether ACPI is supported). Architecture specific code (like GDT and IDT on x86, Paging) is part of the kernel. Also, I would disagree that drivers are targeted code. Architecture specific code should only contain what the kernel needs to initialize itself.