Age | Commit message (Collapse) | Author | |
---|---|---|---|
2023-06-17 | kernel: fix procfs overflow bug, add safeguard to prevent similar ones | 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-11 | kernel: return EPIPE when fs_waiting on a dead filesystem | dzwdz | |
2023-01-06 | kernel: basic procfs | 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-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-20 | user/login: segcmp | 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-19 | syscall/fs_wait: return a handle for each request | dzwdz | |
2022-08-19 | kernel/proc: abstract away managing handles | dzwdz | |
2022-08-12 | vfs: OPEN_RO flag, read-only whitelist entries | dzwdz | |
2022-08-08 | kernel/backend: remove the kern.ready() method | dzwdz | |
2022-08-04 | do some simple TODOs, organize the rest; general code maintainance | dzwdz | |
2022-08-03 | kernel: reuse a single allocation for all vfs_requests of a process | dzwdz | |
$ iostress 32 512 0 > /vtty # before 512 calls, 0 bytes. avg 121133 $ iostress 32 512 0 > /vtty # after 512 calls, 0 bytes. avg 103540 103540/121133 = ~85% I think the tiny bit of added complexity is worth it here. | |||
2022-07-29 | use a shared fs_normslice() function to handle offsets | dzwdz | |
2022-07-27 | kernel/vfs: fix assert failure when creating a vfsreq to a dead mount | dzwdz | |
2022-07-26 | shared: move some headers from shared/ to camellia/ | dzwdz | |
2022-07-23 | init: compile as an elf | dzwdz | |
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: barely boot into kernel code | dzwdz | |
2022-07-08 | syscall/fs_respond: get the file id from the buf argument | dzwdz | |
Previously, file ids could only be positive integers, so their range was 31 bits - not enough to represent the entire memory. Now, pointers can be safely used as file ids. | |||
2022-07-07 | kernel: add the vfsreq_finish_short shorthand function | dzwdz | |
2022-07-07 | kernel/vfs: delegate support in _syscall_fs_respond! | dzwdz | |
this is big in terms of speed, it avoids a lot of unnecessary context switches | |||
2022-06-29 | kernel/vfs: add the OPEN_CREATE flag | dzwdz | |
2022-05-06 | kernel: remove the union in `struct handle` | dzwdz | |
2022-05-06 | kernel/proc: reorganize the functions | dzwdz | |
2022-05-05 | kernel: move fsroot to kernel/arch/i386 | dzwdz | |
2022-05-05 | kernel: each driver registers its own mounts | dzwdz | |
2022-05-05 | kernel: syscalls now have to explicitly save the return value | dzwdz | |
thus they can opt out of doing that so the calls which might return immediately but can return later don't have to both regs_savereturn and return to the caller. and because of that, the return values of a lot of VFS things have just got way saner | |||
2022-05-05 | kernel/proc: remove WAITS4IRQ | dzwdz | |
2022-05-05 | kernel/vfs: refactor vfs_backend to allow multiple kernel backends | dzwdz | |
2022-05-05 | kernel/vfs: rename the vfsreq funcs, merge vfsreq_finish & vfsreq_cancel | dzwdz | |
2022-05-04 | kernel/proc: leave the vfs_request when killing a WAITS4FS proc | dzwdz | |
...instead of letting the hwole process stay around. This could end up a bit more complex, I have no idea how to test killing processes during vfs requests. The upside of this is that I can remove all the deathbed/deadparent weirdness now. | |||
2022-05-04 | kernel: refcount vfs_backend | dzwdz | |
what a mess | |||
2022-05-02 | kernel/vfs: always separately allocate the request object | dzwdz | |
2022-05-02 | kernel/vfs: pass `close()` calls to fs handlers | dzwdz | |
2022-05-01 | kernel/proc: make handles separate refcounted objects | dzwdz | |
2022-04-21 | kernel: recursive kill() | dzwdz | |
2022-04-16 | kernel/vfs: store the queue in `vfs_request` itself | dzwdz | |
2022-04-16 | kernel/vfs: refactor `vfs_request_accept` into `vfs_backend_accept` | dzwdz | |
handling the backend queue makes more sense here than in the syscall implementation. it's also just overall cleaner | |||
2022-04-16 | kernel/vfs: be more strict about the state of `vfs_backend.handler` | dzwdz | |
2022-04-15 | kernel/vfs: don't hang on orphaned vfs calls | dzwdz | |
2022-04-14 | kernel/proc: only change state through `process_transition` | dzwdz | |
2022-04-14 | kernel: slightly clean up `vfs/request.c` | dzwdz | |
2022-04-10 | kernel: idle process | dzwdz | |