summaryrefslogtreecommitdiff
path: root/src/kernel/vfs/request.c
AgeCommit message (Collapse)Author
2024-03-13kernel/malloc: slight rework (it's still bad), store more metadatadzwdz
2024-02-23kernel: knock off some simple vfsreq TODOsdzwdz
2023-06-17kernel: fix procfs overflow bug, add safeguard to prevent similar onesdzwdz
2023-01-25kernel: move /mem/alloc to /malloc and linker.ld to arch/amd64/dzwdz
2023-01-25kernel: consolidate some header filesdzwdz
2023-01-25style: typedef structs, shorter namespacesdzwdz
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-25kernel/virt: replace the virt_cpy api with a more foolproof onedzwdz
2023-01-11kernel: return EPIPE when fs_waiting on a dead filesystemdzwdz
2023-01-06kernel: basic procfsdzwdz
2022-10-08syscall/open: don't check for free handlesdzwdz
doesn't really prevent anything, and makes it harder to test edge cases
2022-10-02syscall/open: add the full suite of READ/WRITE flagsdzwdz
2022-09-20shared: rename ufs_request to better fit its role in userlanddzwdz
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-20user/login: segcmpdzwdz
2022-08-28kernel/vfs: minor vfs_request / vfs_root_register reworkdzwdz
* 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-19syscall/fs_wait: return a handle for each requestdzwdz
2022-08-19kernel/proc: abstract away managing handlesdzwdz
2022-08-12vfs: OPEN_RO flag, read-only whitelist entriesdzwdz
2022-08-08kernel/backend: remove the kern.ready() methoddzwdz
2022-08-04do some simple TODOs, organize the rest; general code maintainancedzwdz
2022-08-03kernel: reuse a single allocation for all vfs_requests of a processdzwdz
$ 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-29use a shared fs_normslice() function to handle offsetsdzwdz
2022-07-27kernel/vfs: fix assert failure when creating a vfsreq to a dead mountdzwdz
2022-07-26shared: move some headers from shared/ to camellia/dzwdz
2022-07-23init: compile as an elfdzwdz
2022-07-17kernel/virt_cpy: error struct, better error handlingdzwdz
2022-07-16amd64: back at the shell!dzwdz
2022-07-16amd64: barely boot into kernel codedzwdz
2022-07-08syscall/fs_respond: get the file id from the buf argumentdzwdz
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-07kernel: add the vfsreq_finish_short shorthand functiondzwdz
2022-07-07kernel/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-29kernel/vfs: add the OPEN_CREATE flagdzwdz
2022-05-06kernel: remove the union in `struct handle`dzwdz
2022-05-06kernel/proc: reorganize the functionsdzwdz
2022-05-05kernel: move fsroot to kernel/arch/i386dzwdz
2022-05-05kernel: each driver registers its own mountsdzwdz
2022-05-05kernel: syscalls now have to explicitly save the return valuedzwdz
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-05kernel/proc: remove WAITS4IRQdzwdz
2022-05-05kernel/vfs: refactor vfs_backend to allow multiple kernel backendsdzwdz
2022-05-05kernel/vfs: rename the vfsreq funcs, merge vfsreq_finish & vfsreq_canceldzwdz
2022-05-04kernel/proc: leave the vfs_request when killing a WAITS4FS procdzwdz
...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-04kernel: refcount vfs_backenddzwdz
what a mess
2022-05-02kernel/vfs: always separately allocate the request objectdzwdz
2022-05-02kernel/vfs: pass `close()` calls to fs handlersdzwdz
2022-05-01kernel/proc: make handles separate refcounted objectsdzwdz
2022-04-21kernel: recursive kill()dzwdz
2022-04-16kernel/vfs: store the queue in `vfs_request` itselfdzwdz
2022-04-16kernel/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-16kernel/vfs: be more strict about the state of `vfs_backend.handler`dzwdz
2022-04-15kernel/vfs: don't hang on orphaned vfs callsdzwdz
2022-04-14kernel/proc: only change state through `process_transition`dzwdz