Действительно ли возможно поддерживать несколько процессов без поддержки Виртуальной памяти?

В древние времена ядро было трудно кодировано для знания устройства главное/незначительное число корневой фс и смонтировало, что устройство после инициализации всех драйверов устройств, которые были встроены в ядро. rdev утилита могла использоваться для изменения числа корневого устройства в изображении ядра, не имея необходимость перекомпилировать его.

В конечном счете загрузчики пришли и могли передать командную строку ядру. Если root= аргумент был передан, который сказал ядро, где корневая фс была вместо созданного в значении. Драйверы должны были получить доступ, это все еще должно было быть встроено в ядро. В то время как аргумент похож на нормальный узел устройства в /dev каталог, очевидно, существует нет /dev каталог перед корневой фс смонтирован, таким образом, ядро не может искать dev узел там. Вместо этого определенные известные имена устройств трудно кодируются в ядро, таким образом, строка может быть переведена в номер устройства. Из-за этого ядро может распознать вещи как /dev/sda1, но не более экзотические вещи как /dev/mapper/vg0-root или объем UUID.

Позже, initrd вошел в изображение. Наряду с ядром, загрузчик загрузился бы initrd изображение, которое было некоторым изображением сжатой файловой системы (изображение gzipped ext2, gzipped romfs изображение, squashfs наконец стало доминирующим). Ядро распаковало бы это изображение в электронный диск и смонтировало бы электронный диск как корневую фс. Это изображение содержало некоторые дополнительные драйверы и сценарии начальной загрузки вместо реального init. Эти сценарии начальной загрузки выполнили различные задачи распознать аппаратные средства, активировать вещи как массивы RAID и LVM, обнаружить UUID и проанализировать командную строку ядра для нахождения реального корня, который мог теперь быть указан UUID, меткой тома и другими усовершенствованными вещами. Это затем смонтировало реальную корневую фс в /initrd, затем выполняемый pivot_root системный вызов, чтобы иметь подкачку ядра / и /initrd, затем должностное лицо /sbin/init на реальном корне, который затем размонтировался бы /initrd и освободите электронный диск.

Наконец, сегодня мы имеем initramfs. Это подобно initrd, но вместо того, чтобы быть изображением сжатой файловой системы, которое загружается в электронный диск, это - сжатый архив cpio. tmpfs смонтирован как корень, и архив извлечен там. Вместо использования pivot_root, который рассматривался как грязный взлом, initramfs сценарии начальной загрузки монтируют реальный корень в /root, удалите все файлы в корне tmpfs, затем chroot в /root, и должностное лицо /sbin/init.