| Age | Commit message (Collapse) | Author |
|---|
|
|
|
History is a circle.
In hindsight that function was pointless, it makes the code more complicated
for pretty much no reason (except saving a few LoC, which is silly).
|
|
I think I've done this refactor in the opposite direction a few years ago.
This is mostly meant to prepare me for setxattr, which requires two inputs -
coincidentally, one is already going to be a kernel input, and the other will
be an user input, so it works out.
I also just didn't like the previous way it worked, this feels cleaner.
|
|
|
|
mostly inspired by Plan 9's Ureg, probably obvious from the name
|
|
|
|
|
|
|
|
This will both let me save space in the allocation header, and make the
debugprint more readable.
|
|
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.
|
|
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.
|
|
This will likely be changed back, but for the time being it will let me
implement a better allocator without too much effort.
|
|
* 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.
|
|
It was a dumb hack that wasn't even necessary - an error when mounting should
shadow over the mountpoint anyways.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not sure how that slipped by
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
dash works now :^)))
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
preparing for HANDLE_PROCFS
|
|
|
|
doesn't really prevent anything, and makes it harder to test edge cases
|
|
|
|
|
|
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
|
