Age | Commit message (Collapse) | Author | |
---|---|---|---|
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 | |
2022-08-22 | syscalls/fs_respond: make the *buf argument const | dzwdz | |
2022-08-19 | syscall/fs_wait: return a handle for each request | dzwdz | |
2022-08-19 | kernel: kzalloc | dzwdz | |
2022-08-19 | kernel/proc: abstract away managing handles | dzwdz | |
2022-08-12 | kernel/proc: don't expose internal fuctions, clean up api | dzwdz | |
2022-08-12 | vfs: OPEN_RO flag, read-only whitelist entries | dzwdz | |
2022-08-11 | kernel/syscalls: merge a few syscalls into vfsop_simple | dzwdz | |
Those had a lot of repeating code, but I'm not sure if this is the right change. Well, apart from making pipe_joinqueue more consistent. | |||
2022-08-11 | kernel: reformat the _syscall dispatch function to a syscall/line | dzwdz | |
2022-08-11 | vfs: support for removing files | dzwdz | |
2022-08-08 | user: separate tmpfs into its own executable, add `mount` | dzwdz | |
2022-08-05 | add _syscall_getsize | dzwdz | |
2022-08-05 | move path_simplify to shared code, move its tests to userland | dzwdz | |