"nightly" versions also allow to use unstable features, and unstable features may remain so for a very long time (potentially forever) without breaking, so an old nightly could maybe work
I read parts of the Linux kernel source code pretty often, and getting the definition of a function is often pretty involved:
- I don't always know the return code type, as the calling code assigned a field whose definition I don't know to find either
- I don't know if it's a C function or a preprocessor macro
This often results in me searching for the exact function name, and combing through the uses in the drivers.
You then need to re-start all that recursively to understand the function you just read.
I could use clangd for that, but I don't have the ressources on my laptop to compile a kernel
I have not really thought too far ahead, I know quite a bit about Linux internals, so when in doubt I tend to follow what was done there. I have not though very far in how to handle most of syscalls, traps, drivers, ...
Thank you for the static site generator! The code highlighting should be very similar to the tokyonight nvim colorscheme, as it uses mostly the same colors & tree-sitter queries as it!
Well yes, but I the main idea of this series is to use no dependencies in order to have a deeper under standing of the entire stack, from boot to GUIs (that is a long term goal!)
I think they meant if you cast a pointer to an integer, do some math on that and then store that. Then you will a stored result that will likely differ from run to run
I think in High-Performance Computing a lot of the networking NICs behave in that way, because you are 100% sure that you know the fabric layout.
Stuff like InfiniBand, HPE Slingshot, Atos BXI, ...
There is a consortium that's building a specification for those kinds of things: https://ultraethernet.org/