| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
this is big in terms of speed, it avoids a lot of unnecessary context
switches
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
what a mess
|
|
|
|
|
|
|
|
|
|
|
|
handling the backend queue makes more sense here than in the syscall
implementation. it's also just overall cleaner
|
