Why so many mounted filesystems on recent distributions?

Question

I've been using Linux on servers since about 1996 and I'm used to seeing something like this:

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3

(I've removed the "options" because they aren't relevant, here.)

Somewhat more recently, I'm starting to see:

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3
devtmpfs on /dev type devtmpfs 
tmpfs on /run type tmpfs 
tmpfs on /run/lock type tmpfs 
sysfs on /sys type sysfs
tmpfs on /run/shm type tmpfs 
devpts on /dev/pts type devpts 

I think I can understand some of these additional items, though they all probably overlap with proc a bit...

I recently grabbed a live ISO image of a desktop distribution (Linux Mint in this particular case, but I've seen it on Debian, Kali, and others), and there is this madness:

$ mount
sysfs on /sys type sysfs 
proc on /proc type proc 
udev on /dev type devtmpfs 
devpts on /dev/pts type devpts 
tmpfs on /run type tmpfs 
/dev/sda1 on / type ext4 
securityfs on /sys/kernel/security type securityfs 
tmpfs on /dev/shm type tmpfs 
tmpfs on /run/lock type tmpfs 
tmpfs on /sys/fs/cgroup type tmpfs 
cgroup on /sys/fs/cgroup/systemd type cgroup 
pstore on /sys/fs/pstore type pstore 
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
cgroup on /sys/fs/cgroup/pids type cgroup 
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
cgroup on /sys/fs/cgroup/blkio type cgroup 
cgroup on /sys/fs/cgroup/freezer type cgroup 
cgroup on /sys/fs/cgroup/perf_event type cgroup 
cgroup on /sys/fs/cgroup/cpuset type cgroup 
cgroup on /sys/fs/cgroup/memory type cgroup 
cgroup on /sys/fs/cgroup/devices type cgroup 
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
mqueue on /dev/mqueue type mqueue 
debugfs on /sys/kernel/debug type debugfs 
hugetlbfs on /dev/hugepages type hugetlbfs 
fusectl on /sys/fs/fuse/connections type fusectl 
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
cgmfs on /run/cgmanager/fs type tmpfs 
tmpfs on /run/user/1000 type tmpfs 
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse 

What is the reason for this proliferation of "mounts"? Are things such as cgroups particularly convenient to view as "mounted" filesystems rather than accessing them through e.g. programmatic APIs?

Answer 1

This is a choice of the kind of API.

On old systems, it was common to use devices and IOCTL on such devices (e.g. to create virtual terminals). The problem were that it rely on using number to have access to a specific service, so it was not easy to improve/upgrade. Additionally the same request number could have a completely different meaning on an other device, so when renaming devices (more descriptive, virtual systems, etc.), it is possible to give the wrong command (e.g. confusing what kind of device should be given to a program).

So there were other alternatives. Some time, new syscall were created, but that mostly for generic cases, and it is also not ideal to create many new syscalls. /proc become also a common interface, but with some problem because the interface of such filesystem (kernel side) is the same for all services. APCI and network used extensively such interface. There were some problem about removing modules while other program had access to their file in proc. Now modules (and thus removing them to free memory) are not so much a problem

Few attempt to use network socket were used, but not so convenient for single uses.

So now it is found easier to create new filesystems and giving some more freedom to drivers/services on how to implement it. There is also an advantage, just cat and echo can be used to get and extract data. so easier to test and to use new features.