Age | Commit message (Collapse) | Author | |
---|---|---|---|
2024-08-02 | *: use a generic UserRegs type everywhere I'm storing registers | dzwdz | |
mostly inspired by Plan 9's Ureg, probably obvious from the name | |||
2024-07-27 | kernel: don't use pointer types for registers, add proc_savereturn | dzwdz | |
2024-07-26 | kernel: implement _sys_intr_return | dzwdz | |
2024-07-20 | *: moving files | dzwdz | |
2024-07-17 | kernel: make kmalloc accept a numeric "tag" instead of a freeform description | dzwdz | |
This will both let me save space in the allocation header, and make the debugprint more readable. | |||
2024-07-14 | kernel: make the adhoc VfsQueue queues use ReqQueue instead | dzwdz | |
I'm still not sure if I should use sys/queue.h for this. But yeah, this is more consistent, and it will also let me switch over to O(1) insertions later on. | |||
2024-07-14 | kernel/malloc: clean up the code a little bit | dzwdz | |
The bitmap functions now accept page addresses so I don't have to handle raw bitmap indexes, which was kinda complex. kmalloc_sanity is now not visible to other code as it wasn't really that useful in the first place. | |||
2024-07-13 | kernel/malloc: limit the maximum allocation size to under a page | dzwdz | |
This will likely be changed back, but for the time being it will let me implement a better allocator without too much effort. | |||
2024-07-11 | kernel: start cleaning up VfsRequest | dzwdz | |
* I'm being more strict about the linked list state to hopefully ensure I'm not leaking any references. * vfsreq_create was renamed to vfsreq_dispatchcopy as that name feels more clear. It copies its argument, and dispatches it. * Requests for user backends are now handled more like requests for kernel backends - there's an accept() function that accepts a request. | |||
2024-05-11 | kernel: remove HANDLE_NULLFS | dzwdz | |
It was a dumb hack that wasn't even necessary - an error when mounting should shadow over the mountpoint anyways. | |||
2024-05-11 | kernel: refactor handle management out of proc.c | dzwdz | |
2024-03-13 | kernel/malloc: slight rework (it's still bad), store more metadata | dzwdz | |
2024-02-23 | kernel: knock off some simple vfsreq TODOs | dzwdz | |
2024-02-23 | kernel: fix _sys_fs_wait in init | dzwdz | |
2024-02-21 | kernel: integrate the proc_ns_next fixes into proc_next | dzwdz | |
2023-12-25 | kernel: _sys_getnull() (basically /dev/null) | dzwdz | |
2023-09-29 | *: properly remove _sys_filicide | dzwdz | |
not sure how that slipped by | |||
2023-09-25 | kernel: remove _sys_filicide (made redundant by _sys_intr) | dzwdz | |
2023-09-25 | kernel/intr: accept a message, allow killing processes via intrs | dzwdz | |
2023-09-24 | kernel: delay removing processes from tree | dzwdz | |
2023-09-18 | kernel: 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-09-17 | kernel/amd64: add HPET support, slightly rework time handling | dzwdz | |
2023-08-31 | kernel: add _sys_getprocfs in place of HANDLE_PROCFS | dzwdz | |
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-29 | kernel: remove _sys_await, emulate it in libc | dzwdz | |
2023-08-27 | ports: qbe, cproc :^) | dzwdz | |
2023-06-17 | kernel: fix procfs overflow bug, add safeguard to prevent similar ones | dzwdz | |
2023-06-11 | kernel: replace await with wait2, roughly compatible with POSIX | dzwdz | |
dash works now :^))) | |||
2023-06-10 | kernel: implement DUP_SEARCH (like unix's F_DUPFD) | dzwdz | |
2023-06-10 | kernel: implement getpid, getppid | dzwdz | |
2023-06-04 | kernel: rework /proc/ and process IDs | dzwdz | |
I'm yet to write proper docs but the TL;DR is: Mounting /proc/ creates a new pid namespace. You're still visible in the old namespace with your old pid, but your children won't be. You see your own pid as 1. Current pids of children will be preserved, pids will be allocated starting from the highest one of your children. | |||
2023-02-23 | toolchain: update, move to a Camellia-specific toolchain | dzwdz | |
2023-01-25 | kernel: move /mem/alloc to /malloc and linker.ld to arch/amd64/ | dzwdz | |
2023-01-25 | kernel: consolidate some header files | dzwdz | |
2023-01-25 | style: typedef structs, shorter namespaces | dzwdz | |
I've wanted to do this for a while, and since I've just had a relatively large refactor commit (pcpy), this is as good of a time as any. Typedefing structs was mostly inspired by Plan 9's coding style. It makes some lines of code much shorter at basically no expense. Everything related to userland kept old-style struct definitions, so as not to force that style onto other people. I also considered changing SCREAMING_ENUM_FIELDS to NicerLookingCamelcase, but I didn't, just in case that'd be confusing. | |||
2023-01-25 | kernel/virt: replace the virt_cpy api with a more foolproof one | dzwdz | |
2023-01-19 | kernel: user interrupts | dzwdz | |
2023-01-11 | kernel: return EPIPE when fs_waiting on a dead filesystem | dzwdz | |
2023-01-08 | kernel: let parents kill their children again | dzwdz | |
2023-01-08 | kernel/proc: don't kill children when parent dies | dzwdz | |
2023-01-06 | kernel: basic procfs | dzwdz | |
2023-01-06 | kernel: turn the NULLFS into an always present special handle | dzwdz | |
preparing for HANDLE_PROCFS | |||
2022-10-08 | kernel/handle: reuse ->writeable/->readable for pipes | dzwdz | |
2022-10-08 | syscall/open: don't check for free handles | dzwdz | |
doesn't really prevent anything, and makes it harder to test edge cases | |||
2022-10-08 | tests: some tests for when a process has no free handles | dzwdz | |
2022-10-02 | syscall/open: add the full suite of READ/WRITE flags | dzwdz | |
2022-09-20 | shared: rename ufs_request to better fit its role in userland | dzwdz | |
The old name could have suggested that it held a response to a request received by fs_wait. The new name is unfortunately very similar to the `struct vfs_request` already used internally in the kernel, but it's better at conveying that it contains a filesystem request yet to be handled. vfs_request - virtual filesystem request (a bad name in hindsight) ufs_request - user filesystem request | |||
2022-09-02 | kernel/proc: introduce child ids for telling children apart | dzwdz | |
2022-08-30 | set up the stack in user/bootstrap instead of the kernel | dzwdz | |
2022-08-28 | kernel/vfs: minor vfs_request / vfs_root_register rework | dzwdz | |
* changed vfs_root_register's name because the _mount didn't add anything * removed the old pointless vfs_backend_tryaccept calls from drivers * because of that, i could remove the vfs_backend globals * replaced the horrible BACKEND_KERN macro * all vfs_backends are now stored on the heap | |||
2022-08-28 | shared/path_simplify: return an unsigned value | dzwdz | |