Building Linux Kernel on MAC Os X

How to write a custom kernel on mac?

There's a few problems with this. First of all, all the compilers you mentioned output either 32-bit or 64-bit code. That's great, but when the boot sector starts, it's running in 16-bit real mode. If you want to be able to run that 32-bit or 64-bit code, you'll need to first switch to the appropriate mode (32-bit protected mode for, well, 32-bit, and long mode for 64-bit).

Then, once you switch to the appropriate mode, you don't even have that much space for code: boot sectors are 512 bytes; two bytes are reserved for the bootable signature, and you'll need some bytes for the code that switches to the appropriate mode. If you want to be able to use partitions on that disk or maybe a FAT filesystem, take away even more usable bytes. You simply won't have enough space for all but the most trivial program.

So how do real operating systems deal with that? Real operating systems tend to use the boot sector to load a bigger bootloader from the disk. Then that bigger bootloader can load the actual kernel and switch to the appropriate mode (although that might be the responsibility of the loaded kernel — it depends).

It can be a lot of work to write a bootloader, so rather than rolling your own, you may want to use GRUB and have your kernel comply to the Multiboot standard. GRUB is a bootloader which will be able to load your kernel from the disk (probably in ELF format) and jump to the entry point in 32-bit protected mode. Helpful, right?

This does not free you from learning assembly, though: The entry point of the kernel must be assembly. Often, all it does is set up a little stack and pass the appropriate registers to a C function with the correct calling convention.

You may think that you can just copy that rather than writing it yourself, and you'd be right, but it doesn't end there. You also need assembly for (at least):

• Loading a new global descriptor table.
• Handling interrupts.
• Using non-memory-mapped I/O ports.

…and so on, not to mention that if you have to debug, you may not have a nice debugger; instead, you'll have to look at disassemblies, register values, and memory dumps. Even if your code is compiled from C, you'll have to know what the underlying assembly does or you won't be able to debug it.

In summary, your main problem is not knowing assembly. As stated before, assembly is essential for operating system development. Once you know assembly thoroughly, then you may be able to start writing an operating system.

How do I cross compile from a Mac to an obscure Linux distribution (embedded)?

This is what I did to compile (Crosscompile? I am not really sure what I did.) bonnie++ on a Mac running VirtualBox with a NAS OS-VM. I think this should apply to most software that one can compile using a simple ./configure; make process.

1. Download NAS OS SDK VM (NASOS_SDK-0.7.ova) from here https://www.seagate.com/nasos/SDK/0.7/downloads/index.html

2. Begun following these instructions https://www.seagate.com/nasos/SDK/0.7/multi-arch/index.html¹ until I reached the section Cross Compiling where I was redirected to https://www.seagate.com/nasos/SDK/0.7/cross/index.html.

3. Skip down to the paragraph that begins with In order to cross-compile our hello program and perform the three exports described there. The TOOLCHAIN_PREFIX can be found in the appropriate directory in /opt: e.g., in the x86_64-seagate-nasos-sdk there is a directory x86_64-seagate-linux-gnu - use that name as the TOOLCHAIN_PREFIX (Why oh why isn't this information included in the guide???).

4. Perform configure and make as described.

Done.

If someone knows how to perform static linking, please add a comment.

¹ I don't think this is necessary if you try to compile something where ./configure; make already works.

https://www.seagate.com/nasos/SDK/0.7/cross/index.html

NAS OS SDK VM

Getting started with OSX kernel programming

Amit Singh's book "Mac OS X Internals" contains a chapter describing the Implementation of HFS+, which might be helpful. If you find resources describing BSD's VFS layer, that might help too, as that's where OS X's VFS layer originates (though with its own page cache, called the Unified Buffer Cache or UBC). Moreover, you could try poking around in the source code of MacFuse and its descendants. Looking at the source of some of the simpler file systems (HFS+ is a bit big for this) will probably also help.

---

Related Topics