This guy is slightly clueless but he has the spirit. I've written my own hobby operating system skeleton and it was a very good learning experience.
Here's a few notes about his plans:
> Target modern architecture
> Avoid legacy, drop it as fast as you can. You can even skip the Protected mode and jump directly to Long mode
I went on and wrote my hobby OS on x86_64 too. Unfortunately, working in x86_64 long mode is a little bit more difficult than using 32 bit protected mode. You can go direct to long mode, but you'll have to write that from scratch. GRUB and other multiboot protocol capable bootloaders set up 32-bit protected mode for you but not long mode. You cannot be in long mode without paging enabled (unlike in protected mode).
So if you want to "skip" protected mode, you'll have to write a pile of assembly code to get there. x86_64 is a lot more work than 32bit x86.
> Jump to C as soon as possible
This is most definitely the right thing to do. Jump into C code as soon as possible. Getting shit done in Assembly is so much slower.
You only need a few pieces of assembly code to get an operating system running: the boot code and the interrupt handler code. The boot code and the interrupt handler are just small trampolines that go to C code as soon as possible.
In addition to the boot and interrupt handler code, you occasionally need to use some privileged mode CPU instructions (disable interrupts or change page table, etc). Use inline assembler for that.
Anyone who (in this thread) suggested using something else than C seemed to be fairly clueless about it. Of the choices you have available, C is the simplest way to go. Everything else is either more work or more difficult.
> Forget old interfaces like PCI, IDE, PS/2, Serial/Parallel ports.
Not so fast. You most likely want to implement a serial console for your operating system. Maybe even add a serial port debugging interface (GDB stubs).
You're most likely going to have to deal with PCI bus at some point too, although many devices don't use the physical pci buses on motherboards, some devices still hook up to the pci bus. Look at the output of "lspci" on Linux, all of those devices are accessed through PCI. This includes USB, PCIe, SATA, IDE, Network interfaces, etc.
Again, using the modern buses is a lot more work than using the old ones and it partially builds upon the old things.
> Why does every tutorial still use such an ancient device as Floppy?
Because when doing a bootloader from scratch for a tutorial, it's a lot easier to use the floppy disk than it is to use a real hard disk or any other media.
> Avoid the use of GRUB or any other multiboot bootloader – make my own and allow only my own OS on the system
No no no. If you want to build an operating system, do not build a bootloader. Use the multiboot protocol and things will be a lot easier. You'll get started so much faster and get to the real stuff sooner. (NOTE: I don't know how UEFI devices boot, it might contain something like multiboot).
Most hobby operating systems are just half-assed stage 1 bootloaders. Just get over the fact that you'll have to use code written by others and get booted.
Popular emulators (bochs, qemu) can boot multiboot kernels directly so you'll save a lot of time there too.
You need to get booted in an emulator and running under a debugger as quickly as possible. Operating system development is so much easier to do with a debugger at hand. Failures generally cause a boot loop or hang the device so there won't be a lot of diagnostics to help with issues.
So my advice is: set up Qemu + GDB + multiboot, and get your kernel booted in a debugger as early as you can.
I won't go into commenting his wacky ideas about VFS structure or APIs. It's nice to make great plans up front but by the time you're booted to your own kernel, a lot of the naïve ideas you started with will be "corrected".
Here's a few notes about his plans:
I went on and wrote my hobby OS on x86_64 too. Unfortunately, working in x86_64 long mode is a little bit more difficult than using 32 bit protected mode. You can go direct to long mode, but you'll have to write that from scratch. GRUB and other multiboot protocol capable bootloaders set up 32-bit protected mode for you but not long mode. You cannot be in long mode without paging enabled (unlike in protected mode).So if you want to "skip" protected mode, you'll have to write a pile of assembly code to get there. x86_64 is a lot more work than 32bit x86.
This is most definitely the right thing to do. Jump into C code as soon as possible. Getting shit done in Assembly is so much slower.You only need a few pieces of assembly code to get an operating system running: the boot code and the interrupt handler code. The boot code and the interrupt handler are just small trampolines that go to C code as soon as possible.
In addition to the boot and interrupt handler code, you occasionally need to use some privileged mode CPU instructions (disable interrupts or change page table, etc). Use inline assembler for that.
Anyone who (in this thread) suggested using something else than C seemed to be fairly clueless about it. Of the choices you have available, C is the simplest way to go. Everything else is either more work or more difficult.
Not so fast. You most likely want to implement a serial console for your operating system. Maybe even add a serial port debugging interface (GDB stubs).You're most likely going to have to deal with PCI bus at some point too, although many devices don't use the physical pci buses on motherboards, some devices still hook up to the pci bus. Look at the output of "lspci" on Linux, all of those devices are accessed through PCI. This includes USB, PCIe, SATA, IDE, Network interfaces, etc.
Again, using the modern buses is a lot more work than using the old ones and it partially builds upon the old things.
Because when doing a bootloader from scratch for a tutorial, it's a lot easier to use the floppy disk than it is to use a real hard disk or any other media. No no no. If you want to build an operating system, do not build a bootloader. Use the multiboot protocol and things will be a lot easier. You'll get started so much faster and get to the real stuff sooner. (NOTE: I don't know how UEFI devices boot, it might contain something like multiboot).Most hobby operating systems are just half-assed stage 1 bootloaders. Just get over the fact that you'll have to use code written by others and get booted.
Popular emulators (bochs, qemu) can boot multiboot kernels directly so you'll save a lot of time there too.
You need to get booted in an emulator and running under a debugger as quickly as possible. Operating system development is so much easier to do with a debugger at hand. Failures generally cause a boot loop or hang the device so there won't be a lot of diagnostics to help with issues.
So my advice is: set up Qemu + GDB + multiboot, and get your kernel booted in a debugger as early as you can.
I won't go into commenting his wacky ideas about VFS structure or APIs. It's nice to make great plans up front but by the time you're booted to your own kernel, a lot of the naïve ideas you started with will be "corrected".
Happy hacking and do not listen to the naysayers.
PS. here's my hobby OS: http://github.com/rikusalminen/danjeros