[haiku-development] [GSoC] x86-64 port

  • From: Duane Bailey <bailey.d.r@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 8 Apr 2010 05:47:20 -0400

Hi, folks, I've submitted my second draft of my proposal for the x86-64; for 
those of who cannot view it, here it is in full (sorry for the poor 
formatting). Any comments, criticisms, suggestions on where to look, 
corrections for incorrect assumptions, etc., would be appreciated. I've been 
studying the source code for about a full twenty hours now, and I'm a far, far 
way from grokking the kernel. I think I have a good enough image for an initial 
plan, though due to technical compilation issues on my mac, I can't poke the 
source code and see what compiles and what doesn't. Thankfully, I'll be going 
home next month to my workhorse which has haiku on the harddrive already.


+ Full name: Duane Bailey
+ Preferred email address: bailey <DOT> d <DOT> r <AT> gmail <DOT> com
+ Trac username: duaneb
+ IRC username: duaneb
+ Summer Education: I am not planning on taking any summer courses.
+ Employment: Google Summer of Code is my only planned employment for the 
+ Schedule: I have no current conflicts. I would be willing to start the 
project early to get a week of vacation with my family in July or August; this 
is secondary, however, and I would be perfectly willing to give Google Summer 
of Code my fully time. In addition, I will probably start researching the 
project, if not starting, soon after I return home from College.
+ Time Allocated: I am currently planning on investing 40 hours a week on the 
+ Internet Accessibility: I have high speed bandwidth at home and where I plan 
on working.
+ Previous Years: This is my first Google Summer of Code application.
+ Brief bio: I've been interested in Programming for over seven years now. My 
father began teaching me to program when I was twelve, now six years ago; my 
first language was java, but increased desire to produce fast programs and 
frustration and Java's restrictions led me to fall in love with C. Though I 
must exercise greater control over my use of the language, C also allows 
greater speed and flexibility when compared to higher-level language. In any 
case, the "safety" that is lost can, again, be assured through careful design 
of the software. Eventually, this interest in computing as close to the 
processor as possible led me to even "lower" levels of software: I delighted in 
writing programs that booted directly from the BIOS, dabbling in all regions of 
kernel land. Since then, I have gone on to learn about the designs of 
processors themselves.
+ For more information, you can read my Resume here: 

+ Project title: Initiate a port of the Haiku Kernel to x86-64.
+ List of project goals
- Port the existing GCC4 branch, forgoing hybrid compatibility, to 
cross-compile to the target Haiku/x86-64.
- Add ELF64 support to boot loader, to facilitate loading of kernel, and add 
support for loading and jumping to a 64-bit kernel.
- Make the kernel compile with the next cross-compiler; comment or stub out 
functionality if it blocks progress.

- Begin to port "essential" modules.
- Add ELF64 support to the Kernel, to finish the loading of the kernel.
- Port basic x86-64 kernel functionality; for this stage, the kernel should 
boot with virtual memory support.
- If I have time….
- A fully-operable 64-bit kernel running a 32-bit userland.
+ Project description: I have some notes on each goal that should help clarify 
my ideas.
- Because hybrid compatibility is not needed for the ELF64-generating gcc, I 
can work straight off of the GCC4 fork, which fully supports x86-64 for other 
operating systems. I hope to draw on the work of the ARM port that took place 
last year to help me. Honestly, this feels like the most daunting step in the 
- The ELF64 support—at least in the boot loader—should also be fairly easy to 
implement; the loader just needs to copy the appropriateparts into memory. 
Additionally, notably different from other loaders, it will be the loader that 
jumps into long mode before jumping to the kernel.
- Porting the kernel—i.e., making it compile—should not be atrociously 
difficult. It looks, from perusing the source code for fifteen to twenty hours, 
that most type issues prone from moving from a 32-bit addressing system to a 
64-bit addressing system are confined to architecture-specific files (i.e. VM, 
cpu, interrupts, syscalls). This is assuming a few things: as long as the int 
type remains 32 bits (the long type can be extended to 64 bits), addr_t is 
typed correctly (it seems to be), and the compiler is free to pack structs as 
needed. One problem that will arise when porting the userland is that the 
syscall api has certain syscalls hardwired to have 32 or 64 bits types; one way 
I would probably avoid this would be to have three types (int23_t, int64_t, and 
addr_t) where the userland and kernel addr_t are the same type.
- Once the kernel has control of the cpu, I would really like to get kernel 
tracing (i.e. dprintf to serial if possible) working for easy debugging. After 
that, however, the ELF64 module loading will be priority to get modules loaded 
and running. I will use the existing elf implementation as a reference, along 
with the ELF64 spec itself, to load the ELF files. I don't see this being 
problematic so much as a slog.
- In line with ticket #1141, I will according begin to port "essential" 
modules—I'm not quite sure which modules these are, but I'm sure that someone 
can help me discern which ones are essential or not. In this case, I'm anxious 
to get the rudimentary drivers necessary for Haiku/x86-64 to boot on QEMU as a 
demo, using the same userspace software. This is the stage that will take the 
longest, if anything: fundamental API changes may be necessary if 
specific-sized data types are expected. Using a data size-agnostic API, 
however, code compiled against x86-64 headers should load just fine into the 
same API; similarly, 32-bit drivers will not be allowed to load into the 
kernel. It is vaguely possible that 32-bit modules may be able to be loaded 
into the kernel with full compatibilities, but this will require fancy loader, 
memory mapping, and/or linker footwork, either using different symbols or 
loading symbols with the same name but different architecture types into 
separate pages, or by simply linking to different symbols for the 64-bit 
- Once modules can be loaded, I will return to the core kernel and implement 
the VM, interrupts, and "x86_64_cpu.c" capabilities. Other things will be 
necessary very soon after, if not immediately, like context switching and 
syscalls, but those are lower priorities.
- Finally—if I have time remaining—I hope to "backwards implement" the cpu into 
a 32-bit emulated cpu. This is fairly standard; Mac OS X did (and does) this. 
Simply: the kernel functions as a 64-bit kernel, even to the drivers, but all 
syscalls and VM requests are implemented as if the kernel were a 32-bit kernel. 
This allows people to run their 32-bit code the same as they used to; each 
process will still have their 32-bit addressing, but the system as a whole will 
be able to reference 256 terabytes on modern hardware and 16 exabytes on 
theoretically true 64-bit addressing hardware. More importantly, this allows 
future developers to use that kernel as a stepping stone to a true x86-64 OS. 
From a technical standpoint, this just means backward supporting the ELF32 
loader, backward-revising it to fit into the compatibility memory model. The 
largest issue will be interfacing the kernel with the userland through 
syscalls, but even this can be remedied by routing the syscall to different 
kernel functions by looking at the "calling" memory page type.

+ Things this project will not do:  This project is not aiming to support SMP, 
any sort of 64-bit userland porting (i.e. a port of libroot), or a mass port of 
modules and drivers. If, however, it appears to be fairly easy when other 
projects are over, additional 
+ Why do you want to work on this project? I believe that the Haiku OS has a 
great potential in the world, combining excellent usability, clean, open-source 
code, and an eye towards the future. I would love to help the project in any 
way possible, but I feel as if my skills and my motivation might be best 
utilized in helping to jumpstart Haiku's use of Intel's x86-64 architecture. 
While a first release is an excellent goal, I feel as if Haiku is leaving many 
features of just about every modern processor untapped; looking beyond Haiku 
R1, I know that any progress made this early will be a benefit to the project's 

Other related posts: