summaryrefslogtreecommitdiff
path: root/src/libk/include
AgeCommit message (Collapse)Author
2024-08-17*: getxattrdzwdz
2024-08-02*: use a generic UserRegs type everywhere I'm storing registersdzwdz
mostly inspired by Plan 9's Ureg, probably obvious from the name
2024-07-27kernel: don't use pointer types for registers, add proc_savereturndzwdz
2024-07-26kernel: implement _sys_intr_returndzwdz
2024-07-25kernel: pass more information to user on interruptdzwdz
This is meant to facilitate a syscall for returning from interrupts, which will actually work in the general case as opposed to the current hack, which only works if the interrupt occured during a syscall (which is correct... for now).
2024-07-20*: moving filesdzwdz
2024-07-16kernel: use a slab allocator for kmallocdzwdz
For a while during development it managed to be faster than the old allocator despite having more overhead, probably because it makes better use of the cache. It no longer is - not sure why. The code definitely could be optimized to hell, though, and it'd probably recover its original edge. Non-power-of-2 sizeclasses would be really useful, as I could then e.g. fit four processes into a page instead of three, but I think implementing them "well" would be too complicated for now. In hindsight arbitrary allocation descriptions were probably a bad idea too. I've kept them in for now, but I'll switch to an enum of allocation types soon. I think I can fit all the per-allocation state (size+type) in 2 bytes. There are so few allocations in the kernel that I no longer care about the backtraces, so I'm leaving them out. The "large" allocations could probably be tested with execbuf in userland, so I might actually implement them soon too.
2024-07-13kernel/malloc: limit the maximum allocation size to under a pagedzwdz
This will likely be changed back, but for the time being it will let me implement a better allocator without too much effort.
2024-05-11kernel: DUP_RDONLY and DUP_WRONLYdzwdz
I probably should've tested DUP_WRONLY too, now that I think about it. TODO?
2024-05-11kernel: remove HANDLE_NULLFSdzwdz
It was a dumb hack that wasn't even necessary - an error when mounting should shadow over the mountpoint anyways.
2023-12-25kernel: _sys_getnull() (basically /dev/null)dzwdz
2023-12-25ports: curl :^)dzwdz
had to do a lot of hacky stuff, but it's there. worked on this on and off for a while now
2023-09-25kernel: remove _sys_filicide (made redundant by _sys_intr)dzwdz
2023-09-25kernel/intr: accept a message, allow killing processes via intrsdzwdz
2023-09-18kernel: implement _sys_time()dzwdz
After some consideration this seems like the most fitting way to handle timekeeping. Directly, the syscall is only useful for keeping time within a single process, but it is meant to be used for e.g. NTP clients, which will provide the real time through the VFS.
2023-08-31kernel: add _sys_getprocfs in place of HANDLE_PROCFSdzwdz
This makes the side-effects more explicit, and feels less hacky than `HANDLE_PROCFS`. I don't think accessing a handle alone should have side-effects, even if it's a "special" one.
2023-08-29kernel: remove _sys_await, emulate it in libcdzwdz
2023-08-24libc: get most of binutils to compiledzwdz
2023-08-17build: rework how sysroots workdzwdz
/usr/include is now built on the fly, letting me merge include files from multiple modules, which should be a win for organization later on. binutils & gcc need to be recompiled. limits.h shamelessly stolen from heat on #osdev, as gcc stopped providing me with its own header. which was a hack in the first place
2023-08-14reorganization: first stepsdzwdz