***ChanServ sets mode: +o rekado
<stikonas>oriansj: any preference on how we select linux vs UEFI in M2-Planet? <stikonas>define that we need to pass via command line? <stikonas>actually not in M2-Planet but we'll need to do it in M2-Mesoplanet <oriansj>stikonas: how does --host posix vs --host UEFI vs --host bare-metal sound? <oriansj>or maybe --operating-system posix vs --operating-system UEFI vs --operating-system none <oriansj>possibly --operating-system linux so that we have different folders for the *BSDs and the rest <stikonas>or do other posixes follow linux syscall numbers <oriansj>no, they do not (even have radicially different calling conventions) <muurkha>stikonas: a lot of other OSes support running Linux binaries now, for which purpose they support the Linux syscall numbers and calling conventions <oriansj>as we can set that with -D when we build M2-Mesoplanet <stikonas>I think M2-mesoplanet does default to host arch already <stikonas>I've barely started looking and porting M2libc <oriansj>but it is something to think carefully about as changing it in the future might be more complex <stikonas>hmm, why do we have mknod so early, just because it was easy to add? <oriansj>and for setting up /dev/null if I remember correctly <oriansj>and we can sort it out later if we choose to build anything more advanced than M2-Mesoplanet on UEFI <stikonas>oriansj: hmm, what do you think I should do with void* malloc(unsigned size) function <stikonas>but I need a different implementation that does not use brk <stikonas>so I guess I should move it to linux dir... <stikonas>oh, maybe I can just use defines in the file <oriansj>or just make the brk function in UEFI <stikonas>hmm... might need to rething how I allocate memory <stikonas>but one page might be disconnected from the other <stikonas>well, maybe I can hide it somehow in brk implementation <stikonas>maybe, that would still work in linux... <stikonas>so maybe we just improve that malloc in top-level stdlib.c <oriansj>well it definitely would work on linux and enable us to have proper free() as well <oriansj>it just involves us adding a bit of complexity but nothing too serious <oriansj>the first block would be enough to track 4GB of RAM <stikonas>I'll have to read up a bit more on slab allocators... <stikonas>so 1st block will store some kind of map? <oriansj>basically we can only cut a block in half 4MB, 2MB, 1MB, 512KB, 256KB, 128KB, 64KB, 32KB, 16KB, 8KB, 4KB, 2KB, 1024, 512, 256, 128, 64, 32, 16, 8, 4bytes <oriansj>and we allocate the first block that is big enough <oriansj>although that might make a problem if we need to allocate more than a single block for a single object <stikonas[m]>Yeah, we can't guarantee that blocks are next to each other... <oriansj>but I guess we could add logic for merging of blocks but then we would need more tracking logic <stikonas[m]>But I guess we rarely have allocations if more than 4MiB in calloc <oriansj>say use an integer to store the 2^n size <oriansj>then we have a pointer to the base address <oriansj>so the first block is just an array of structs {int size; void* base;}; <stikonas[m]>On uefi we can't guarantee that blocks are next to each other....