Re: [make-initrd] Fwd: Re: [devel] Запрос на фичу liveboot в make-initrd

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Fri, Apr 27, 2018 at 12:26:09AM +0300, Leonid Krivoshein wrote:
> Ещё пару слов о пропагаторе с Вашим кодом из make-initrd. В виртуалках 
> QEMU и VirtualBox загрузка не сломалась, напротив, сеть теперь 
> находится.

Рад слышать.

> С тем же эффектом мы проверили его на дюжине машин, найдя 
> одну проблемную, где старый пропагатор запнулся с поиском флэшки, а 
> новый нет. Ещё на одной машине по сети удалось загрузиться, даже 
> несмотря на очень необычную ситуацию, когда сеть не пойми как работает, 
> DHCP-сервер в железной CISCO, PXE-сервер в виртуалке VMware, а сетевая 
> карта болтается соплёй от USB.

Скорее всего это из-за того, что ipconfig использует очень старый dhcp,
который руками разбирается.

> Тем не менее, к старому коду вопросы есть.

make-initrd-0.8.x ?

> Во-первых, судя по документации, udevadm control --reload-rules (теперь
> вроде так это называется) делать после запуска демона udevd
> необязательно.

Ну нужно. А кто его делает ?

> Во-вторых, сейчас задержка на поиск сетевой карты получилась 15 секунд
> (итераций), тогда как для CD-ROM/флэшек она составляет фактически 32+15
> секунд (итераций) -- несправедливо!

Я не считал итерации. Возможно.

> В-третьих, самый непонятный для меня вопрос 
> с udevadm settle --timeout=5. Получается, мы просим его подождать 
> появления железа с 5-секундным таймаутом

Этот таймаут на очередь, чтобы не ждать слишком долго.

> Я так понимаю, чтобы отработали скрипты/правила udev'а после 
> нахождения этого железа.

Нет. Это просто ожидание инициализации железа после загрузки модуля ядра.
Если всё проинициализируется раньше, то `udevadm settle` выйдет раньше
таймаута.

> В отличии от пропагатора, в make-initrd задержка стоит в 
> 1/10 секунды в бесконечном цикле с общим ограничением по времени. Но в 
> целом, получается, что Ваш код более рабочий, а я не очень хорошо знаю 
> udev, если честно...

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

Остальной код реагирует на определённые эвенты. Но мы не знаем, когда
появятся условия для монтирования корня. Поэтому там бесконечный цикл.

-- 
Rgrds, legion