Writing your own working OS for half a year
Hello! I strongly welcome everyone, today I would like to tell you about my experience in writing a workable OS for the x86 architecture.
One spring night I had a brilliant idea - try yourself in writing your own OS, which can allow you to run programs, work with devices, and generally squeeze all the power out of Intel's architecture in your needs: for example, for your factory or something else. My goal was and is to write such an OS that could allow maximum performance for some specific tasks without spending CPU time on all sorts of excesses. Basically, I pursue only sports interest, gaining experience for myself in system programming and writing drivers for devices that are used everywhere. What came of it is up to you, I immediately say that you don’t need to write comments about creating your own Linux distribution, and pursued the interest to write everything from scratch - from scratch, in order to dive well into the theme of OSDev. Just want to express my deep gratitude to Benjamin Lunt and the OSDev forum, as well as their wiki. Ben helped me deal with EHCI, which undoubtedly made a huge contribution to my OS - USB devices, they are everywhere! I was also faced with the task of creating my own architecture, convenient for me, not excluding the use of ELF file standards.Well, let's get to the point.
UPD: all the info can be found in the pump group , there is also a post with docks and a way (old, now I finish writing docks for the stable version)
What is done?
Now my OS is able to work with USB flash drives, mice, keyboards, AHCI disks, PCI IDE controller, APIC and ACPI, preemptive multitasking is implemented, program launch is implemented, streamlined work with files, SVB driver that runs on 0x118 VBE mode, DNS, DHCP, TCP, UPD, IPv4, HTTP, full FAT32 driver, RTL8139 (69) driver and Intel Gigabit Ethernet work.
The window system along with my SVGA implementation makes it possible to give as much as 120 FPS when the screen is completely redrawn. Let's move on to how this is all implemented and generally can work.
How it works?
To begin with, I wrote a bootloader that reads the secondary bootloader with the kernel from FAT32. The second boot loader switches to protected mode and jumps to the kernel, where I load and configure IDT, then initialize the PCI devices, launch the kernels, and launch CMD.
Someone will ask, how did you achieve such a performance with SVGA? The answer is simple: assembler, assembler and assembler again. Not without SSE instructions that greatly speed up the copying of memory. For example, here is the code for copying the video buffer in the LFB (Linear Frame Buffer):
.byte 0x60#Save registers in stack mov %2,%%ecx #Repeat count to ecx mov %0,%%edi #Video memory startto edi mov %1,%%esi #Video buffer startto esi ww1sse2: movaps (%%esi),%%xmm0 #Copy16 bytes to xmm0 from buffer movaps %%xmm0,(%%edi) #Copyfrom xmm0 to video memory movaps 16(%%esi),%%xmm0 #16 again, but + 16fromcurrent movaps %%xmm0,16(%%edi) #16 again, but + 16fromcurrent movaps 32(%%esi),%%xmm0 #16 again, but + 32fromcurrent movaps %%xmm0,32(%%edi) #16 again, but + 32fromcurrent movaps 48(%%esi),%%xmm0 #16 again, but + 48fromcurrent movaps %%xmm0,48(%%edi) #16 again, but + 48fromcurrentadd,%%edi #Add64 bytes to edi add,%%esi #Add64 bytes to esi dec%%ecx#Decrement count #test %%ecx,%%ecx #Compare ecx with zero jnz ww1sse2 #Ifnot zero, repeat again .byte 0x61 #Restore registers from stack
The window system is built on the OOP and, I think, does not need comments, everything is almost like in the Shinde.
The memory manager is the simplest - “Watermark Allocator”. Resource allocation is carried out due to the fact that there are no functions in the kernel that could spoil each other, all requests are made through queues, etc.
So far, there are no I / O streams, but they will be implemented soon.
The logical disk system is similar to MS-DOS: one letter - one disk. Both MBR partitions and GPT partitions are supported.
Device driver development
It didn’t do without it - taking someone else’s code is somehow uncivilized and not practical, if you dig out the Linux repositories, you can get lost.
To be honest, I support the fact that the main thing in the program is functionality, but at the same time I think that it is possible to sacrifice a bit of functionality for the schedule: for example, VIM.
Of course, this was the most interesting development stage: to read tons of documentation, and then understand that you set return for debugging, because of which part of the structure was not filled at all. I think that it is good enough to make you strain your brain, because even after the tenth reading of the docks, some aspects still remain incomprehensible to you, and you have to do long debugging on real hardware.
Debugging the OS takes a huge heap of time: compile the scales, copy to a virtual disk, save the disk image, check on the emulator, then copy the files to the USB flash drive and check it on real hardware. And most importantly - no debuggers, output to text mode, or in the windows - hung - put return'y.
Yes, the OS is still in the development stage, I want to get a stable beta version for the new year, and maybe even continue to develop at a more serious level in the future.
What I want to say at the end - if someone interested in the OS development topic, or someone wants to learn aspects of working with any devices and interfaces, implementation tricks, or just help the project (not with money, but with code), you can write about it in comments, all wishes will be taken into account, and the aspects you are interested in will be described in details and colors.
Only registered users can participate in the survey. Sign in , please.