ядро, initramfs и драйвера видеокарты

управление процессами, памятью

Так оно уже в ядре. Это, простите, его обязанности. И initramfs грузит не ядро, а загрузчик. Делает он это перед тем, как загрузить ядро. Когда в память загружено ядро и initramfs, загрузчик передает управление ядру и оно уже само разбирается.

Или все-таки ядро? Надо почитать.

Здесь сказано, что все запускает загрузчик. Так что изначально я был прав.

Я, возможно, не так выразился. При запуске ядра запускается та часть, которая отвечает за основу работы - управление процессами, планировщик, управление памятью и т.д. и т.п. Но вот ядро увидело какое-то железо кроме проца и памяти - допустим, видеокарту. Ему ж не сдалась эта видеокарта, пока какой-то софт не попросит загрузить драйвер этой видеокарты. Но это обычно происходит после того, как ядро запускает систему инициализации, когда запускается udev. Но ядро зачем-то грузит драйвер видеокарты еще до запуска системы инициализации, еще когда использует initramfs. И вот я хочу понять - это его grub заставляет сделать, передав ему параметр splash?

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

это grub говорит ядру загрузить драйвер видеокарты для splash скрина?

Нет. Груб загружает ядро. Все. Ядро находит инитрамфс (для этого груб передает ему параметры, где искать). Ядро начинает исполнять стартовые скрипты из инитрамфс. Именно они выбирают и запускают драйвер. Груб может передать ядру параметры, касающиеся драйвера. А как с этими параметрами поступить, должно быть в скриптах инитрамфс.

Если эти экзотические устройства нужны еще на стадии запуска системы (еще до монтирования корня). Если система и без них запустится - то нет смысла их добавлять в initramfs.

То есть в каких-то стартовых скриптах инитрамфс прописана необходимость загрузки видеодрайвера не из корня, а из initramfs? Зачем? Из-за plymouth? А если убрать splash из grub, всё равно будет грузиться видеодрайвер еще на стадии initramfs?

пока какой-то софт не попросит загрузить драйвер этой видеокарты

В том-то и дело, что без драйвера софт в принципе не будет знать про видеокарту. Нет драйвера — система не может общаться с устройством. Так что драйвер должен быть загружен заранее. И модуль — это не часть ядра. Это кусок когда, который может подгружаться в кернелспейс.

Под софтом я имел ввиду udev. Кусок кода, расширяющий функционал ядра - ну это часть ядра, вынесенная в отдельные файлы, загружаемые при необходимости. Считаются ли они частью ядра или нет - разве есть официальное мнение? В целом код, выполняемый в kernel space, можно назвать ядром - значит и модули являются ядром. Нет?

Ты можешь загрузится и без видеодрайвера. Но тогда система не обнаружит видеокарту и вывести информацию на экран. А до запуска инита и монтирования корня ядро может грузить только то, что есть в initramfs. Прикол в том, что может быть ситуация, что для работы с файловой системы нужен модуль, который лежит в корне, который отформатирован в эту самую файловую систему. Если модуль есть в инитрамфс, ядро может смонтировать файловую систему.

можете, пожалуйста, прочитать вопрос? Если бы я не знал, что такое initramfs, я бы не задавал этот вопрос.

В целом код, выполняемый в kernel space, можно назвать ядром

Нет. Если ты вкомпилил драйвер в ядро — это действительно часть ядра. А модуль — это просто кусок кода, который загружается в пространство ядра.

А если убрать splash из grub, всё равно будет грузиться видеодрайвер

Естесственно. Иначе ты не увидел бы лог загрузки.

необходимость загрузки видеодрайвера не из корня, а из initramfs?

Для уменьшения «мельканий экрана». Какой-то драйвер все-равно нужен. Фрамебуфер тоже имеет свой драйвер. Во времена, когда драйвера не было в инитрамфс, сначала загружался некий универсальный драйвер, чтобы на экране хоть что-то могло показываться. Потом уже загружался основной драйвер, в этот момент экран моргал. Помимо прочего, это требовало больше времени.

Если система и без них запустится - то нет смысла их добавлять в initramfs

Да. Но запускается и нормально работает — это разные понятия. Если нужно, чтобы устройства нормально проинициализировались во время загрузки — их драйвера должны быть в initramfs.

И то и другое - модули ядра, просто одни встроенные, другие подгружаемые (built-in и loadable). И если их отличает просто вкомпилено оно или нет (что позволяет выгружать вторые) - то это всё можно назвать частью ядра.

Ладно. До монтирования корня ядру доступно только то, что есть в initramfs. Что ты туда засунул — то оно и загрузит.

И вот тебе статейка про kernel modules

Ну не совсем. Ядро будет грузить только то, что ему нужно. Так то сейчас в initramfs пихают чуть ли не все драйвера. Ядро, конечно, прогрузит что-то по минимуму, потом, как я понял, скрипты изи initramfs прогрузят что-то дополнительное «для удобства», а дальше уже после запуска системы инициализации «для всего остального есть udev».

для всего остального есть udev

Без драйверов udev ничего с твоим устройством не сделает. так что в инитрамфс должны быть все устройтсва, которые надо инициализировать во время загрузки.

та я знаю, уже десяток ссылок перерыл, включая эту. Сам как раз пишу про ядро и модули, и где-то натыкался, что вроде нет единого мнения - являются ли модули частью ядра или нет. Да, это куски кода, вынесенные в файлы. Но, имхо, модули = часть ядра, потому что «ядро отвечает за работу с дисками», а не «куски кода, подгружаемые в ядро, отвечают за работу с дисками». Хотя, конечно, второе точнее, но и первое я тоже считаю правильным. Сам по себе кусок кода бессмысленный, это часть ядра.

Ладно. На основной вопрос я ответил?

ну не знаю - вроде как именно udev отвечает за загрузку драйвера в ядро, и железо вполне можно проинициализировать «при включении компьютера после монтирования корня», ничем это не отличается от «в перерыве пока есть initramfs но нет корня».

https://i.stack.imgur.com/GFA8G.png

p.s. но модули можно грузить и без udev, как видимо происходит в скриптах initramfs

Ну в целом ответ про «Для уменьшения «мельканий экрана»» может сгодиться, хотя, конечно, это усложняет работу (вся эта ситуация с двойными драйверами, блоклистом nouveau и т.п.)

udev — управление устройствами для новых версий ядра Linux, являющийся преемником devfs, hotplug и HAL. Его основная задача — обслуживание файлов устройств (англ. device nodes) в каталоге /dev и обработка всех действий, выполняемых в пространстве пользователя при добавлении/отключении внешних устройств, включая загрузку firmware

Это из википедии. udev работает на уровне юзеспейса. Если он обслуживает диск, уже должен быть прогружен ядерный дравер, отвечающий за sata-контроллер.

Короче, ядерными драйверами он не заведует.

ну диск отложим в сторону - без него не прогрузился бы корень, не хочу опять говорить о смысле initramfs. Хотя именно udev даёт имена дискам и т.п.

Юзерспейсом называется всё, кроме kernel space. Включая систему инициализации и т.п. Сетевые карты и прочее железо (по идее включая видеокарту), которые не являются необходимым минимумом для base kernel, подгружает udev.

Но в целом да, разработчики дистров могут просто прописать всё нужное еще до udev, как это сделали с видеодрайвером, из-за чего страдает моё представление - initramfs нужен только для монтирования корня, ядро при запуске прогружает только минимум, а дальше udev из юзерспейса загружает всё необходимое.

Вот

Да. Таки udev загружает модули. Статья на АрчВики

Да, на википедии очень невнятно это расписано. Но вот еще хороший пример - https://unix.stackexchange.com/questions/127005/how-does-init-determine-which-devices-to-modprobe

EXPORT HARDWARE INFORMATION TO USERSPACE (SYSFS)
*NOTIFY USERSPACE TOOLS THAT HARDWARE IS AVAILABLE (UEVENT AND UDEVD)
    Yeah, your assumption is correct. udev has something to do with the magic :)*
PROCESS UEVENTS, MATCH THEM AGAINST RULES IN /ETC/UDEV/RULES.D/ AND POPULATE /DEV DIRECTORY (UDEVD AND UDEV)
LOAD DEVICE DRIVERS (UDEV, MODPROBLE)
NOTIFY USERSPACE APPLICATIONS (THROUGH D-BUS)

Даже не так. Статья про udev на АрчВики

udev — работающая в пространстве пользователя система, с помощью которой системный администратор может создавать обработчики событий. События, получаемые udev, обычно генерируются ядром Linux в ответ на физические события, происходящие с периферийными устройствами. Например, при обнаружении периферийных устройств или «горячем» подключении udev может выполнить определённые действия, в том числе и вернуть управление ядру, если необходима загрузка модулей или прошивок.

То есть, я был прав, когда написал, что udev не заведует ядерными драйверами. Он может перелатьт ядру управление при необходимости, и ядро само загружает драйвера и файлы прошивок.

Ну, сам udev не может «загрузить модуль», он же не является частью ядра, но udev, как я понимаю, запускает modprobe, который и говорит ядру загрузить модуль. Потому что вроде именно udev решает, делать modprobe или нет.

В целом, возможно, я ошибаюсь, но кажется раньше ядро делало modprobe само, при виде нового оборудования, но с появлением udev это начал делать он.

Кто-то может поправить?

То есть, драйвер видеокарты таки необязательно совать в initramfs. udev может сказать ядру прогрузить его уже после монтирования корня и запуска инита. Но лучше, как мне кажется, встроить этот драйвер в initramfs.

Хотя, скорее всего, я был неправ.

https://unix.stackexchange.com/questions/421456/why-udev-is-loading-two-kernel-modules-for-a-single-usb-device

In other words, this udev rule is not loading the r8152 driver, it’s switching the device to the correct mode for that driver if necessary.

When a new device is added, Linux kernel basically runs modprobe with the hardware IDs (and some other things) of the device encoded in the «name» of the module it requests. This «name» is then compared by modprobe to wildcard strings embedded into each module as module aliases.

да нафига встраивать, при загрузке сойдёт efifb/vesafb. а в самосборном ядре можно вкомпилить

Это похоже на то, что написано в арчвики. udev ловит события, генерируемые ядром и решает, что делать дальше. В том числе, он может вернуть управление ядру, которое загрузит модуль.

Я кажется понял. udev не совсем решает, грузить модуль или нет, ядро вроде как в любом случае грузит, но вот с какими аттрибутами решает udev.

Например правило udev: SUBSYSTEM==«usb», ACTION==«add», ATTR{removable}==«removable», ATTR{idVendor}==«04e8», ATTR{idProduct}==«6860», ATTR{authorized}=«0»

То есть вроде как флешка будет прогружена, но её параметр authorized будет 0.

Спасибо, что находишь время зайти и объяснить. Видно что ты гоаоришь то в чем разбираешься.

Да, тут я выразился неправильно. Система не может работать с устройством без драйвера. Но ядро может установить сам факт наличия этого устройства, если поддерживает протокол, по которому устройство подключается.