linux

Yes. Fortunately, these definitions are significantly less complex than libc stuff. They all use typedefs prefixed with __kernel that are defined in asm and asm-generic headers. The Linux kernel headers with all relevant structure definitions are here: https://github.com/torvalds/linux/tree/master/include/uapi

The source is published to GitHub though, no? https://github.com/torvalds/linux It's an easy mistake to make, the code is there and there's nothing to suggest it's a mirror.

The historical reason is https://github.com/torvalds/linux/pull/17#issuecomment-56546... Perhaps some of these issues have been fixed by now, but the Linux project has been going on just fine without GitHub (git was even invented for the Linux kernel project itself even before GitHub existed) so there doesn't seem to be any reason to switch even if all the mentioned problems were to be fixed

Interesting. That code will only need to the "stat" files of processes in userspace, so it's correct for its use-case. But you're right that a more general parser would need to ignore what proc(5) has to say about the limit, and parse up to a limit of 64. As far as I can tell the difference is because when you call prctl(2) with "PR_SET_NAME" it will get truncated to the "TASK_COMM_LEN" that proc(5) discusses. See this code in kernel/sys.c: https://github.com/torvalds/linux/blob/493ffd6605b2d3d4dc700... This is the linux.git commit that changed it, before that kernel worker threads had to obey the same limit, it was first released with linux v4.18: https://github.com/torvalds/linux/commit/6b59808bfe482642287...

They actually allow up to 64 characters in the kernel: https://github.com/torvalds/linux/blob/8395ae05cb5a2e31d3610... This might just be for certain kernel things though. I don't see any regular processes that aren't truncated, but I see a bunch of kernel things that have more than 16 chars on my system.

The Linux kernel has not historically had great unit testing practices--it's mostly tested with large integration tests. This is in part because it inherits old development practices where unit testing was less popular, and partially because it's kind of hard to test a lot of Kernel code outside of specialized environments (e.g., would need to include a m68k emulator in the test environment to test this code). The doubly-linked `list` type that's used ~everywhere in the kernel didn't have any in-repo unit tests until 2019 ( https://github.com/torvalds/linux/commit/ea2dd7c0875ed31955c... ), after kunit, a library for userspace testing of kernel code, was added.

I don't know. Judging from source blame, flagfile has been in gflags since 2007 at the latest, and 2007 is also when the command line length limit was lifted: https://github.com/torvalds/linux/commit/b6a2fea39318e43fee8...

I don’t know if this will help you but it is at least a nice list in a plain text file — intel-family.h from the Linux source tree: https://github.com/torvalds/linux/blob/master/arch/x86/inclu...

https://sourcegraph.com/github.com/torvalds/linux is a more featured search engine with limited go-to-definition functionality, and removes the need to clone locally and search in many cases. Can be used with any GitHub repo. Just make sure to first enable "case sensitivity" and "structural search" using the buttons in the right of the search textbox so that the search is exact (which is a task that GitHub's own search fails at).

Kernel parameters are usually documented in the kernel-parameters.txt file in the source. See https://github.com/torvalds/linux/blob/master/Documentation/...: hpbussize=nn The minimum amount of additional bus numbers reserved for buses below a hotplug bridge. Default is 1. The way to get from the error "No bus number available for hot-added bridge" at https://github.com/torvalds/linux/blob/master/drivers/pci/pr... to this specific kernel param is still a bit involved.

That makes sense, so I just picked another commit at random without a -rc tag: https://github.com/torvalds/linux/commit/c60c152230828825c06... The fix is to change && to || This seems like the exact type of bug that a unit test could prevent.

> ... there are a bunch of internal APIs: linked lists come to mind. Those already have unit tests: https://github.com/torvalds/linux/blob/master/lib/list-test.... using an existing in-kernel test framework no less. If you step up into the 'lib' directory (containing generic in-kernel utility code) you might notice that there are a whole bunch of C files already that have an "_test" suffix in their name (or "_kunit").

> Do you really need tests for the read(2) syscall when Linux is running on a billion devices, and that syscall is called some 10^12 times per second globally? Maybe not, but isn't it true that any new code that is being added to the kernel has been run on exactly 0 devices? And new code is being added all the time. Maybe that's why the most recent commit as of right now is loaded with fixes of broken things: https://github.com/torvalds/linux/commit/08ad43d554bacb9769c... It's one thing to say that it's impossible to test effectively locally before release (which I'm not sure if that's true or not). But you're saying it's just not worth testing because it'll break in real life and that's even better, which I"m not sure I can agree with.

That function is the heart of the page allocator inside the Linux kernel [1]. The fundamental building block for every memory allocation on any system (running on Linux). Whether you call malloc() in a C program, kmalloc() inside a kernel driver, the new operator in C++, load a file in python, or almost any other operation, it will ultimately end up in __alloc_pages() (for small objects, multiple units will share a single __alloc_pages(), then there is a fine grain object manager on top of that such as Slab/Slub, jcmalloc, tcmalloc, mimalloc, etc. but you got the point). [1] https://github.com/torvalds/linux/blob/c3eb11fbb826879be773c...