Add some documentation

docs/1_system_startup.md

@@ -0,0 +1,8 @@
+# System Startup
+
+The Matos operating system is supposed to be started unsing a bootloader that is [multiboot](https://www.gnu.org/software/grub/manual/multiboot/multiboot.html) compatible.
+As such, it can receive some information about the host such as memory size, layout, video mode supported ...
+
+When the booloader is ready, it will call the `_start` function as it is described as the entry point by the `linker.ld`.
+The `_start` function is defined in ASM under the `arch/$ARCH/boot/boot.S` directory.
+It will setup the stack and few other things like the bss section before calling the `kmain()` function from `core/main.c`

docs/2_physical_mem_setup.md

@@ -0,0 +1,26 @@
+# Physical memory setup
+
+The Physical memory definition stand in the `mem.h` file.
+To keep track of it, the memory is split in chunk of `PAGE_SIZE`. The chunks are then represented by the `struct phyMemDesc` structure.
+
+This structure is a double-linked list allowing us to hold some information on every page like its address and the number of time it is used. Yes, the same physical page could be shared by several different sub-system. 
+
+The system keep track of 2 such linked list. One with the allocated/used (`phyUsedPage`) page. One with the free one (`phyFreePage`).
+
+## Initial `struct phyMemDesc` allocation and setup
+
+Just after system startup, there is no memory allocator setup, and yet we have to store the information about all the physical pages.
+
+For example, if the system was made of 4 MB of memory, we have `4MB/PAGE_SIZE` to store.
+Thanks to `linker.ld` script we have a symbol in C (`__ld_kernel_end`) defining the last address of memory used by the code. So we can compute the needed size to store the structures and book the space after `__ld_kernel_end` for this.
+So from `__ld_kernel_end` to `__ld_kernel_end + MEM_SIZE/PAGE_SIZE` is an array of `struct phyMemDesc` describing all the memory of the computer by chunk of `PAGE_SIZE`
+
+
+We can setup the pages between `__ld_kernel_begin` and `__ld_kernel_end +MEM_SIZE/PAGE_SIZE` as being used and read the information from the bootloader to setup the free pages.
+We will keep one exception for x86 and keep page bellow 0x100000 as used because they are physically mapped to some functions like VGA.
+
+## Allocator
+
+Having lists of used or free physical page make it easy to create a physical page allocator that consist of:
+* allocation: Get a `phyMemDesc` from `phyFreePage` and put it in `phyUsedPage`
+* free: make sure the page is not used anymore and put it in the `phyFreePage` 

docs/3_virtual_mem.md

@@ -0,0 +1,65 @@
+# Virtual Memory
+
+## Introduction
+
+The virtual memory is a memory management system that translate, on the fly, some "ideal" memory address to some real physical memory address.
+It's well described on, for example, [wikipedia](https://en.wikipedia.org/wiki/Virtual_memory).
+
+Here we choose to implement Virtual memory using pagination only. So we keep segmentation configured as a single `flat` model (c.f. `core/gdt.c`).
+
+The paging is mainly implemented in `arch/ARCH/paging.c`.
+
+## x86 and mirroring
+
+We need a way to access and modify the record doing the translation `virtual memory -> physical memory` for the MMU.
+On x86, this register is called the `PD` or Page Directory.
+Once the paging is enabled on the CPU, we use a trick call `mirroring` to access and modify the PD and its content.
+So now, we have a way to map a physical memory page to any given virtual page.
+
+### PD implementation details
+
+In a virtual addr(Vaddr), 10 first bit (MSB) are the index in the Page Directory.
+A Page Directory Entry point to a Page Table. The 10 next bits are then an index in this Page Table. A Page Table entry then point to a physical address at which is added the remaining 12 bits. 
+So they are 1024 entry in the PD, each of them pointing to a PT of 1024 entry.
+Each PTE pointing to 4K page.
+First address (up to pageDesc from mem.c) are mapped such as Paddr == Vaddr. To make PD always accessible a (x86?) trick is used : The mirroring. 
+A given entry N in the PD point to the PD (this is possible because PDE very looks like PTE in x86). So N << (10 + 12 = 4Mo) point to the Paddr of PD.
+Then, accessing N * 4Mo + I * 4Ko is accessing the PT of the Ieme entry in the PD (as MMU take the PD pointed by the PDE number N like a PT).
+More particularly, accessing N * 4Mo + N * 4ko is accessing the PD.
+
+PD is at Vaddr N * 4Mo and take 4ko. Each PT are allocated dynamically.
+Just make sure that N have not been used by identity mapping
+
+## Virtual memory allocators
+
+We will setup 2 different virtual memory allocator:
+* `allocArea` for large memory area of several PAGE_SIZE size
+* `alloc` for object of any size
+
+With each needing the other (`allocArea` need `alloc` to allocate `struct memArea` to keep track of the area and `alloc` need `allocArea` to allocate large memory size) we need to make sure that there is no forever loop.
+
+### `AllocArea`
+
+An area is represented by `struct memArea` and basically consist of a virtual memory address and a size if number of page.
+This is a simple allocator keeping 2 linked list of used/free area.
+
+Allocating a new area (thanks to `areaAlloc()`) consist of:
+1. finding an area big enough in the free list.
+2. split it if the found area is too large.
+3. put the found area in the user area list.
+4. optionally map the area to physical page
+
+Freeing an area (thank to `areaFree()`) consist of trying to find adjacent free area and merge them with this one or just adding the area to the free one.
+
+### `Alloc`
+
+
+For large object allocation ( > PAGE_SIZE), this a basically a call to `areaAlloc()`.
+For smaller object, this is a more complex allocator based on the concept of slab.
+
+The allocator is configured at startup to maintain slab for allocating object of a given size.
+So a slab is a linked list of `struct slabEntry` having each of the entries pointing to one or several memory area that is divided in chunk of the slab configured size.
+It's a linked list so it is each to add a new `struct slabEntry` when one is full.
+Inside a `struct slabEntry` the `freeEl` attribute point to the next free chunk (of the slab configured size) in the allocated page(s). At this address is also a pointer to the next free area in this area. 
+
+