vercas / beelzebub Goto Github PK

It kind of needs to validate itself...
Also, gotta change the flags of the pages associated with the data sections 'n stuff.
Oh, and lastly, parsing the symbol table, so I can display exactly where exceptions came from.

A decent way is required for presenting situations from which the kernel cannot recover.
Also, it is mandatory that I halt all processing units on such event.

I suppose the data should be saved somehow and somewhere unless it could change (I should look into that).

I estimate tens of instances of __bland __forceinline...

There should be an ACL for syscalls, so only specific processes can use specific syscalls.
For instance, InitRD-related syscalls should only be available to the init process and filesystem server.

Typically, when a process spawns another, it should be able to specify an ACL mask, to limit permissions.

I will be using the page map for info and O(1) deallocation of a single page (instant check).
A stack will be used for storing free and caching page indices. This allows O(1) allocation of a single page.

Reserved pages should stay forever reserved, so there is no point in storing them in a stack.
Used pages don't need specific storage. When used pages need to be used (e.g. reallocation to make room for consecutive pages), the map needs to be looped over anyway.

I do not believe I will need to allocate consecutive physical pages often, and I really do not like the implications of every algorithm that would allow quicker multi-page allocation.

The same "stack" will contain both free and caching pages, but the stack will have two "tops". The caching pages sit above the free ones.
E.g. when a free page is popped, the free top decrements, the top caching page is written in its place and the caching top decrements. Performance should be satisfactory.

I need to plan in advance the way the kernel will structure the virtual memory space for itself and for processes.
It should be compact and scale nicely.

I should use shiny diagrams.

Note: "Virtual", in this context, means the same as "linear" in x86 terminology.

It is vital that Beelzebub begins to use 2-MiB pages where possible.
These have their own TLBs in L1 and share entries with 4-KiB pages in L2.
Therefore, using 2-MiB pages allows threads and cores to handle significantly larger working sets, which is handy for both the kernel and especially userland.

This requires support from the PMM, which needs to provide aligned pages.

Thus, the following must be implemented:

Plans

• Simplify and abstract away interface of the PMM; no need for consumers to know every little detail.
  • Expose simplified PMM to kernel modules.
• Change physical allocation space to work with 2-MiB frames.
  • Serve 4-KiB frames from within 2-MiB frames. Management structures for the 4-KiB frames should be within the 2-MiB frame.
  • Use frame dangling at the end of the allocation space, if any.
  • Use frame at the start of the allocation space, if any.

Seriously, how has this not been done? It seems like such a great idea :P

A set of syscalls is required to allow the initialization application to inspect the InitRD, and to deal with kernel modules.

• InitRdList - Lists all entries in a directory within the InitRD.
• InitRdFind - Attempts to get a handle on an item within the InitRD.
• InitRdGetInfo - Retrieves information about the given InitRD item from its handle.
• InitRdLoad - Loads the given InitRD item from its handle into the specified chunk of memory.
• KmodList - Lists loaded kernel modules (as handles).
• KmodGetInfo - Gets information about the given kernel module by handle.
• KmodLoad - Loads a given kernel module (from either an InitRD item handle or a chunk of memory), returns handle.
• KmodUnload - Unloads the given kernel module by handle.

I really should write the specifications of the various components involved in the code.
I suppose the preferred location would be the wiki on GitHub.

I'll do it in the kernel first, but the bootloader is going to need this as well for things like LAPIC version, SMP...

The kernel needs a table of handles in the system, with a reference count, process ID, and index within that process's handles.
Each process needs a table to map local handle indexes to global handles.

• Settle on the proposed structures of the two tables.

• Implement kernel handle table

  • Make fast path wait-free
  • Investigate need for garbage collection

• Implement process handle maps

  • [ ]

TODO: Finish the checklist...

As it says on the tin.

Jegudiel needs to parse command-line arguments.

Will look into:

• Kernel's module name..?
• Framebuffer (i.e. VBE) font

At least for a single processor - the BSP.
This is gonna be interesting.

There's a lot of spaghetti in the dependencies right now.
For instance, the AMD64 paging structures depend on the base terminal!

This needs fixing right away.

• MemoryCheck- Check whether a chunk of memory meets the given criteria.
• MemoryChange- Change permissions of a given chunk of generic non-free memory.

More may come.

At least a light mutex for page (de)allocation.

I should implement many more, for later usage.

Allocate paging tables, set 'em up, change CR3.
Oh, and I definitely must remember that each CPU will have its own set of tables and CR3 value.

Hi @vercas ! I just noticed that Beelzebub's ISO size from the latest release is just 830 KB - so it seems that Beelzebub could fit inside a floppy! Even today the floppies are still being used, for example - as virtual floppies inside the coreboot open source BIOS. Just imagine: your wonderful OS could be a part of someone's BIOS build! (for coreboot supported motherboard, maybe you have or could get one - see https://www.coreboot.org/Supported_Motherboards )

Please tell , are there any planned Beelzebub releases in a floppy format? (even 2.88 MB is supported, although 1.44 MB will be preferred because a space inside a BIOS flash chip is very limited, could be just 4 MB total with about 3 MB free space left for floppies after the primary BIOS part)

I need string.h and decent implementations for x86 to move forward.
Also, proper tests...

There's an insanely smart way I came up with to parse the memory map and instance the allocation spaces in the most optimal way possible (for my structures).

However, implementing it would take weeks! Even if I had a heap to (ab)use, it would require several days to implement and perfect.
The fact that I have to work with constant memory only makes it more difficult.

The algorithm is way too complex to describe, but I can hopefully remember it and implement it sometime in the future.

For the time being, I am simply instancing an allocation space per available map entry.

I must check the indentation, the commenting style, the documentation style (where present), I must make sure const is after the type that it applies to, I must check the alignment of arguments in function declarations and calls...
Shouldn't really take that long, considering that I've been doing this for a while.

Perhaps I should document the coding style.

The pages above 4-GiB won't work with hardware that uses 32-bit addresses.
Therefore, it will be useful if generic pages are allocated above 4-GiB if available, to maximize the number of pages usable by such hardware.

On IA-32 with PAE (and AMD64 before switching to long mode), CR3 is 32 bits wide so the relevant table must be located under 4-GiB as well.

I'd rather build this into the generic page allocator because it is a situation that can happen on more than one architecture. Also, it will allow for slightly more compact storage.
I should also move the map and the stack at the end of the allocation space.

The memory between 1-MiB and 16-MiB is now free and will be used for ISA DMA.
I should map it and prepare it for use.

Dumping registers 'n all that jazz. It will be vital for... everything.
Oh, and halting execution would be prudent.

With freenode now being the propaganda machine of some self proclaimed korean royalty, it may be wise to move the ##beelzebub channel to some other IRC server or chat platform