Walk the custody cache and try to reuse an existing one when possible.
The VFS is responsible for updating them when something happens that would
cause the described relationship to change.
This is definitely not perfect but it does work for the basic scenarios like
renaming and removing directory entries.
We definitely need to replace m_executable before clearing interrupts, since
otherwise we might call ~Custody() which would make it assert in locking.
Also avoid calling FileDescriptor::metadata() repeatedly and just cache the
result from the first call.
I also added a comment at the point where we've decided to commit to the new
executable and follow through with the swap.
When encountering a symlink, we abandon the custody chain we've been working
on and start over with a new one (by recursing into a new resolution call.)
Caching symlinks in the custody model would be incredibly difficult to get
right with all the extra invalidation it would require, so let's just not.
The current working directory is now stored as a custody. Likewise for a
process executable file. This unbreaks /proc/PID/fd which has not been
working since we made the filesystem bigger.
This still needs a bunch of work, for instance when renaming or removing
a file somewhere, we have to update the relevant custody links.
A custody is kind of a directory entry abstraction that represents a single
entry in a parent directory that tells us the name of a child inode.
The idea here is for path resolution to produce a chain of custody objects.
Probably doesn't actually change much yet since we don't support many
text rendering options, but it's at least good to have the options, and
to record things we don't yet support too.
If I'm understanding the standard C library correctly, setenv() copies while
putenv() does not. That's really confusing and putenv() basically sucks.
To know which environment variables to free on replacement and which ones to
leave alone, we keep track of the ones malloced by setenv in a side table.
This patch also moves Shell to using setenv() instead of putenv().
Fixes#29.
Right now, we allow anything inside a user to raise or lower any other process's
priority. This feels simple enough to me. Linux disallows raising, but
that's annoying in practice.
It can't be 100% precise but it doesn't really matter. Use this to implement
realloc() nicely. This also fixes a bug in realloc() where we didn't take
the size of the allocation metadata into account when computing the size of
an allocation backed by a BigAllocationBlock.
links requests SO_ERROR, so in not supporting it, things were unhappy.
Supporting this properly looks a little messy. I guess Socket will need
an m_error member it sets everywhere it returns an error. Or Syscall
could set it, perhaps, but I don't know if that's the right thing to
do, so let's just stub this for now and file a bug.
We were only reusing the existing allocation if the new requested size
was exactly the same as the fudged size of the block. This meant that
realloc() could allocate a new block even though the new block would be
identical to the old block.
Also run it across the whole tree to get everything using the One True Style.
We don't yet run this in an automated fashion as it's a little slow, but
there is a snippet to do so in makeall.sh.
