| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It was a good idea, but it didn't even work. 0/10
Maybe I should replace it with semgrep someday.
For the only current rule, I can split src/kernel/ into src/kernel/{amd64,generic},
and just don't have amd64 in generic's include path.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
If gcc is built with a different $PREFIX than binutils, it won't even
attempt using them - it will use the system assembler instead, which
fails for obvious reasons.
|
|
It compiles, but the resulting gcc binary doesn't actually work.
Maybe it's too new for the binutils?
|
|
|
|
|
|
Currently it just checks if the kernel doesn't accidentally use
arch-dependent headers.
|
