5 ms·

Learning curve for kernel development gets steeper and steeper, and there seems nothing we can do about it. It's a well designed machine already, so we might n

Learning curve for kernel development gets steeper and steeper, and there seems nothing we can do about it. It's a well designed machine already, so we might not care about it slipping into the realm of mysterious black boxes, but someday it's going to become one. A black box that exceeds human understanding

woodruffw 6y ago
IMO, individual parts of the Linux kernel are still relatively digestable. I had never looked at this particular part before, and I could figure out maybe 95% of the behavior with a few hours of close reading (which, IMO, is a reasonable amount of time for a piece of code that's outside of both userspace and peeks under C's semantics to do trampolines, etc). My experience so far (mostly writing kernel modules) is that the complexity comes from discovery, not the actual code itself: I have a much harder time finding the right APIs to use than I do actually writing things once I'm on the right track.
- korethr 6y ago
  I haven't done any kernel programming yet, but the curiosity has been there. What has been your main difficulty in finding the right APIs? Lack of documentation? Poor or unclear documentation? Something else?
  - woodruffw 6y ago
    > What has been your main difficulty in finding the right APIs? Lack of documentation? Poor or unclear documentation? Something else? Definitely poor (or more often, old) documentation. In particular, this has popped up for me when trying to write modules that add entries to procfs or sysfs: these interfaces are documented and widely used, but much of the documentation is years old and the APIs (or their best practices) have changed subtly. My best reference has just been the subsystem source itself, as well as other kernel modules that I know work. Another thing that pops up: the Linux kernel is so big and has so many architecture-specific subtrees that it can be difficult to find the "effective" definition for some function or macro. Woboq and Elixir help with this a bit, but it's very easy to go down a rabbit hole.
  - mhh__ 6y ago
    Kernel documentation isn't great, and it tends to be distributed as one big long-form text file. This has it's benefits because it encourages explaining the rationale behind a given design, but it also means that you can end up with rotten old information looking just as recent as the new stuff. Man pages often don't actually cover a complete listing of everything an API has, too. eBPF is a good microcosm of this, where using it isn't all that complicated but actually working out what to do can take ages because most resources use a middle-man to talk to the kernel.
studius 6y ago
> and there seems nothing we can do about it. The complexity's moving into the hardware, so I wouldn't assume the kernel'd be having to handle this sort of thing in 50 yrs.
- loa_in_ 6y ago
  That's a very interesting take. I wonder how extensive future SoC will be, and how close to "thinking silicon" will we get.

woodruffw 6y ago

IMO, individual parts of the Linux kernel are still relatively digestable. I had never looked at this particular part before, and I could figure out maybe 95% of the behavior with a few hours of close reading (which, IMO, is a reasonable amount of time for a piece of code that's outside of both userspace and peeks under C's semantics to do trampolines, etc). My experience so far (mostly writing kernel modules) is that the complexity comes from discovery, not the actual code itself: I have a much harder time finding the right APIs to use than I do actually writing things once I'm on the right track.

korethr 6y ago
I haven't done any kernel programming yet, but the curiosity has been there. What has been your main difficulty in finding the right APIs? Lack of documentation? Poor or unclear documentation? Something else?
- woodruffw 6y ago
  > What has been your main difficulty in finding the right APIs? Lack of documentation? Poor or unclear documentation? Something else? Definitely poor (or more often, old) documentation. In particular, this has popped up for me when trying to write modules that add entries to procfs or sysfs: these interfaces are documented and widely used, but much of the documentation is years old and the APIs (or their best practices) have changed subtly. My best reference has just been the subsystem source itself, as well as other kernel modules that I know work. Another thing that pops up: the Linux kernel is so big and has so many architecture-specific subtrees that it can be difficult to find the "effective" definition for some function or macro. Woboq and Elixir help with this a bit, but it's very easy to go down a rabbit hole.
- mhh__ 6y ago
  Kernel documentation isn't great, and it tends to be distributed as one big long-form text file. This has it's benefits because it encourages explaining the rationale behind a given design, but it also means that you can end up with rotten old information looking just as recent as the new stuff. Man pages often don't actually cover a complete listing of everything an API has, too. eBPF is a good microcosm of this, where using it isn't all that complicated but actually working out what to do can take ages because most resources use a middle-man to talk to the kernel.

studius 6y ago

> and there seems nothing we can do about it. The complexity's moving into the hardware, so I wouldn't assume the kernel'd be having to handle this sort of thing in 50 yrs.

loa_in_ 6y ago
That's a very interesting take. I wonder how extensive future SoC will be, and how close to "thinking silicon" will we get.