Linux – How to find out which Linux kernel versions are the most prevalent

Is is as simple as comparing /proc/filesystems with lsmod?

No:

$ comm -31 <(lsmod | awk 'NR!=1 {print $1}' |sort) \
           <(</proc/filesystems awk '{print $NF}' |sort) | fmt
anon_inodefs autofs bdev cgroup cpuset debugfs devpts devtmpfs ext2 ext3
fuseblk fusectl hugetlbfs mqueue nfs4 pipefs proc pstore ramfs rootfs
rpc_pipefs securityfs sockfs sysfs tmpfs

Many of these are not built into the kernel on that system. autofs is provided by a modules called autofs4 while nfs4 is provided by a module called nfs. The ext4 module provides ext2 and ext3 as well as ext4; fuse provides both fuseblk and fusectl. rpc_pipefs (not to be confused with pipefs) is provided by sunrpc.

Yet your system is able to load a module for a filesystem on demand: when you run mount -t foo …, if foo isn't a supported filesystem type, Linux attempts to load a module that provides this filesystem. The way this works is that the kernel detects that foo isn't a supported filesystem, and it calls modprobe to load a module called fs-foo. The mechanism is similar to pci:… aliases to load the driver for a PCI hardware peripheral by its PCI ID and usb:… which is similar to USB — see How to assign USB driver to device and Debian does not detect serial PCI card after reboot for more explanations. The fs-… module aliases are recorded in /lib/$(uname -r)/modules.alias. This file is generated when you build the kernel.

Under normal conditions, you can use this to determine which filesystems are provided by modules. By elimintation, the filesystems that are not provided by modules are built into the kernel. There are rare edge cases where this approach wouldn't work, for example if you've modified or erased your modules.alias file, or if a filesystem is provided both by a module and in a compiled-in form. I don't know of a way to cope with these cases short of writing some kernel code and loading it as a module.

for fs in $(</proc/filesystems awk '{print "fs-" $NF}' |sort); do
  /sbin/modprobe -n $fs 2>/dev/null || echo "$fs is built in"
done

Q1: “It” is wake_up. It wakes up all tasks that are waiting for the disk data. If they weren't waiting for that data, they wouldn't be waiting on that queue.

Q2: I'm not sure I understand the question. Each wake queue entry contains a pointer to the task. try_to_wake_up receives a pointer to the task that it's supposed to wake up. It is called once per function.

Q3: There are lots of wait queues. There's one for every event that can happen. The disk driver sets up a wait queue for each request to the disk. For example, when the filesystem driver wants the content of a certain disk block, it asks the disk driver for that block, and then the request starts with the task that made the filesystem request. Other entries may be added to the wait queue if another request for the same block comes in while this one is still outstanding.

When an interrupt happens, the disk driver determines which disk has data available from the information passed by the hardware and looks up the data structure that contains the kernel data for this disk to find which request was to be filled. In this data structure, among others, are the location where the data is to be written and the corresponding wake queue indicating what to do next.

Q4: The process makes a system call, let's say to read a file. This triggers some code in the filesystem driver which determines that the data needs to be loaded from the disk. That code makes a request to the disk driver and adds the calling process to the request's wait queue. (There are actually more layers than that, but you get the idea.) When the disk read completes, the wait queue event triggers, and the process is thus removed from the disk's wait queue. The code triggered by the wait queue event is a function supplied by the filesystem driver, which copies the data to the process's memory and causes the read system call to return.