[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.
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.
Other related posts:
