passing kernel info, update docs

docs/boot.md

@@ -2,10 +2,49 @@
 
 ## Basic Information
 
-Kimi's Bootloader is a custom booting solution and the default bootloader for Kimi's OS on legacy BIOS systems. It loads the default x86 GDT to be used by the Kernel, along with any disk or filesystem modules which may be present in the files `ddrv.mod` and `dfs.mod`
+Kimi's Bootloader is a custom booting solution and the default bootloader for Kimi's OS on legacy BIOS systems. It loads the default x86 GDT to be used by the Kernel.
 
 The bootloader also sets the video mode to the closest mode present to Standard definition, and obtains the BIOS memory map to be passed to the Kernel. 
 
+### Features
+
+It's not very feature rich, cause it's whole purpose was to do the bare minimum for what i needed for my own project. While I've made bootloaders before, they've typically only consisted of some code that gets a memory map, sets up a gdt, and says "fuck it, i'll load these next 64 sectors, why not?" however i wanted to do everything a bit better, make things easier on me in the long run, and now i have a bootloader that does the same thing but
+
+- searches and loads any file named "kernel.elf" into memory (only supports legacy filenames for now, LFNs to be supported at a later date
+
+	(note: this only works in the root directory, if not found, the bootloader will simply hang and spit out some error code
+- parses the ELF format for information on how to accurately map the Kernel in virtual memory
+
+	(note: this only really works if segments are page-aligned. TBH even once I have C code working if I ever want to try and work with non-page-aligned ELF files...)
+
+- Gathers a map of memory to pass to the loaded kernel
+
+#### What I want to add
+
+- Recursive directory searching
+
+	I want to be able to load the kernel file from another directory, just to keep things more organized. Like booting from some file path like `/sys/kernel32.elf` instead. This kind of goes hand in hand with implementing LFNs, but i do NOT want to deal with those right now
+
+- Config files
+	
+	Yeah, it's cool and all being able to load a file and properly map everything. Hell, someone could even theoretically write their own kernel and replace the kernel.elf file and it'd work fine upon restart, but why do that when I can be even more convoluted and choose to boot Linux from my glorious homebrew bootloader (theoretically)
+
+- Module loading
+
+	Since i want to have a modular kernel, I'll need to somehow load modules for disks and filesystems at boot time. While I would do this now, I don't have any modules to boot, nor a kernel to use said modules, so I'm going to hold off on this until I'm a bit into my kernel and start needing actual modules. (It's going to be So Fun making this work. Maybe I'll just load the file and have the kernel take care of symbol patching?) this also requires reading and parsing config files, which I am not ready to start working on... Yet. 
+
+- Multiboot support
+
+	Yeah passing information from a non-standard struct to my kernel is nice and all, but you know what else is nice? allowing my kernel to actually use other bootloaders other than those designed specifically for my kernel. I could try to detect whether or not i'm using my own struct or a multiboot struct, but why do that when I can just support one?
+
+- Selecting video modes that most closely align with monitor's real size
+
+	This would be great to have, and while I have implemented it in a previous bootloader, I don't understand the code anymore and am not comfortable just copy-pasting the entire thing and praying that it works somehow.
+
+- Selecting better load/copy addresses
+
+	On loading the kernel file, I just pick some arbitrary, pre-chosen spot and say "yeah, this is good enough", but in reality i have on average only 400-ish kb until i start to overwrite the EBDA (which is bad, i do enjoy having ACPI). Instead, I want to implement a function to actually look for a continuous point in memory that is large enough to hold the entire kernel (ELF headers and all) without accidentally overwriting important information or running into memory barriers/holes.
+
 ### A20 Line
 
 Due to the fact that many x86 PCs POST without enabling the A20 line, the bootloader attempts to enable it through 3 distinct methods, starting with 

src/kernel/entry.s

@@ -31,5 +31,5 @@ _start:
     jmp $
     
 section .data
-string: db "Why even use grub at this point?", 0xa, 0xd, "https://github.com/notsomeidiot123 | someidiot321 on Reddit :3", 0xa, 0xd
+string: db "Why even use grub at this point?", 0xa, 0xd, "https://github.com/notsomeidiot123 | someidiot332 on Reddit :3", 0xa, 0xd
 db "Check comments for more info ^^", 0x0