| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 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 | |
| 2022-08-04 | do some simple TODOs, organize the rest; general code maintainance | dzwdz | |
| 2022-08-04 | syscalls: add _syscall_sleep() | dzwdz | |
| 2022-07-29 | syscall/write: WRITE_TRUNCATE | dzwdz | |
| 2022-07-29 | syscall: up the max argument count to 5; make write accept flags | dzwdz | |
| 2022-07-26 | shared: move some headers from shared/ to camellia/ | dzwdz | |
| 2022-07-20 | user/elf: free memory not belonging to the elf when jumping to it | dzwdz | |
| 2022-07-18 | syscalls: implement execbuf | dzwdz | |
| i have been planning to implement something like this for a while now. it should be faster when doing consecutive syscalls (to be tested). it will also be helpful in writing the elf loader | |||
| 2022-07-17 | kernel/virt_cpy: error struct, better error handling | dzwdz | |
| 2022-07-16 | amd64: back at the shell! | dzwdz | |
| 2022-07-16 | amd64: init can print to the terminal now | dzwdz | |
| 2022-07-16 | amd64: seemingly working syscalls (SYSCALL/SYSRET) | dzwdz | |
| 2022-07-10 | syscalls: implement dup | dzwdz | |
| 2022-07-09 | syscalls/pipe: turn into a POSIX-style api with separate rw ends | dzwdz | |
| Without separate read/write ends you can't tell when there are no more writers left if you have multiple readers. Consider this piece of code: int fd = pipe(); fork(); // execution continues in 2 processes while (read(fd, &some_buf, sizeof somebuf) >= 0) { ... } Once both processes call `read()`, it's obvious that no writes are possible - all the processes that hold a reference to the pipe are currently stuck on a `read()` call, so the kernel could just make it return an error in both. But, what then? It's still possible to write to the pipe, and you can't know if the other process will do that. Thus, if you don't want to miss any output, you have to keep reading the pipe. Forever. Both processes end up stuck. Having separate read/write ends prevents that. | |||
| 2022-07-08 | kernel/proc: remove the type argument from process_handle_get | dzwdz | |
 |
index : camellia | |
| Unnamed repository; edit this file 'description' to name the repository. |
| summaryrefslogtreecommitdiff |