>>20099>Actually, it's not that the source code is hard to read
If you can't navigate and understand the codebase, it's said you "can't read" the code.
Knowing english doesn't mean you'll make sense of a difficult book.>>20092>prevent sensitive data from being paged out
man mlock(2) and man setrlimit(3) to disable coredumps>>20100> a way to address the inodes directly
No, it is filesystem specific and theres not much you can do from userspace. As a kernel driver, however, it's often possible to address filesystem by inodes (for example nfs servers do that, so they dont need to keep per file clientstate).>>20091
>Where are Linux system calls documented?
Syscalls are documented in mangpages in section 2 (section 3 means library wrapper). These typically directly translate to kernel syscalls 1:1, but not always.
>Are system calls a stable interface or am I expected to always use glibc?
Yes they are guaranteed to stay between kernels (linus "dont break userspace ever"), but are not "same" between architectures. For example pipe() interface is architecture specific, as wella s handling of varargs. Some archs have socketcall sub-api, some dont ...
>Why is Windows the only OS with I/O Completion Ports?
Linux IO is process/thread oriented deep inside kernel design (a block io request is ultimately always tied to a thread). On windows, all IO is a callback, which is why you can have APC for IOPL. That said, windows IO still massively underperforms compared to modern linux.
>Linux non-blocking I/O vs. kqueue
epoll and kqueue are architecturally comparable. on linux you can of course too get signal and inotify via epoll - the difference is that linux kernel apis provide just basic building blocks, instead of opaque tools. this is most visible with iptables vs ipfw/pf.
bsd kqueue is unified interface, but internally it of course treats signals differently from block io or directory notify.
Closest relative would be CreateEvent. Both eventfd and createevent can be used to implement IPC semaphores. If you don't know how IPC events are useful, first ask about that.
>What's the one true way to handle signals?
I'm inclined toward windows/plan9 approach (queued packet of data). Unix bitmap model (and limited depth rtio) is unfortunate legacy we have to live with.
>Apparently, I can't return normally from a SIGSEGV handler since it'd go right back to the instuction that caused the fault. I reason that the same restriction applies to the other three signals.
Note that the only acceptable use for that is handling of null dereferences and COW GC. If you use it for something different, your design is seriously broken.
If you want to continue after handling fatal fault, you need an instruction decoder. You need it to figure out what exactly has happened in the first place. Note that this is usually not the case with things like null - you simply longjmp to upper stack frame exception handler (as null deref is simply always exception).
Use libevdev, raw evdev ioctls are not guarateend to be stable.
>How are libraries such as libdl implemented?
Read their code. Basically just mmap() and ton of elf format bookkeeping.
>You said you'd discuss how the OS loads program images. Is that functionality exposed by the kernel somehow, or am I expected to load programs myself?
Kernel is not involved in pure userspace things such as dlsym/libdl aside from providing mmap() and execve(). In particular, it does not deal with ELF symbols at all (unless were talking about kernel modules).