Writing your own working OS for half a year

    image

    Prehistory


    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$64,%%edi	#Add64 bytes to edi
    	add$64,%%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


    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.

    Results


    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.

    Ethical hacking!

    Only registered users can participate in the survey. Sign in , please.

    Are you interested in this topic?


    Also popular now: