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. Thanks! + 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 summer. + 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 project. + 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: https://s3.amazonaws.com/drb-storage/Resume.pdf. + 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 project. - 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 version. - 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 future.