[make-initrd] [PATCH v6 21/22] bootchain-core: adds ability to bring the daemon to the foreground

[Leonid Krivoshein]

06.11.2021 18:22, Alexey Gladkov пишет:
> On Sat, Nov 06, 2021 at 05:57:44PM +0300, Leonid Krivoshein wrote:
>>> Так я же и написал tty2. Вопрос был о том, зачем демону перезапускаться ?
>>> Он же может перенаправить свой ввод-вывод на любой терминал.
>> Перенаправить-то он может свой ввод/вывод, но на переднем плане (на tty2)
>> продолжает работать одна часть (перезапущенная), в то время как другая часть
>> следит за истечением таймаута, чтобы переключиться на этот терминал (tty2).
>> Есть условия, при которых мы должны переключаться на tty2 сразу, но данное
>> разделение и перезапуск через openvt позволяют реализовать концепцию
>> отложенного переключения на tty2. Иначе мы должны были бы переключиться туда
>> немедленно и наблюдать все быстро проскакивающие диалоги, например, в
>> течение первых 3-6 секунд загрузки altboot. Данное концептуальное усложнение
>> позволило избавиться от мелькания диалогов на ранней стадии загрузки, когда
>> никакого ввода от пользователя не требуется, и вся загрузка укладывается в
>> отведённые 8 секунд таймаута.
> Я с трудом понимаю.
>

Мы сейчас работаем с третьей реализацией bootchain. Первую без диалогов 
ты видел и комментировал. Во второй было всё просто: один монолитный 
пакет, переключение на tty2 и обратно через chvt с перенаправлением в/в. 
В ней была отмечена проблема быстрого мелькания диалогов, также 
описанная в этом баге: #30472. Разделение на процессы, перезапуск через 
openvt сделаны для решения этой проблемы, а также для очистки за собой 
этой интерактивной консоли, для работы с ещё одной служебной консолью, 
на которую выводится журнал отладки. Т.е. первый процесс контролирует 
или ждёт остальные запущенные процессы.

Уже не помню всех шагов своих экспериментов, но кажется, если 
использовать tty2 без openvt -w ..., не получалось реализовать вариант, 
при котором демон отрабатывает на tty2 и удаляет за собой всё, не только 
чистит экран, даже в случае fatal(). А запуск через openvt подразумевал 
перезапуск части процесса.


>>>> Алексей Шепляков предложил тут хорошую идею: использовать для тех же целей
>>>> screen или tmux. Собственно задача: восстановить после себя консоль. Вариант
>>>> идеальный, но у меня пока не вышло из-за проблем с настройкой utf8 в stage1,
>>>> там одно другое цепляет, есть конфликты с plymouth и kbd, который сейчас,
>>>> кажется, совсем нерабочий.
>>> Кто совсем нерабочий ?
>> make-initrd с фичей kbd у меня не собирается, фейлится.
> # grep kbd /var/lib/initrd/`uname -r`.initrd/features
> kbd
>
> Эта фича срабатывает в момент инициализации терминалов.
>
>> Вообще не проблема руками настроить консоль и utf8. Но проблемы
>> начинаются, когда это начинают делать сразу несколько фич, когда с
>> ресурсами типа tty2 или console начинают работать несколько разных фич,
>> типа plymouth, kbd, rdshell.
> Я не вижу проблем с kbd+rdshell. Насчёт plymouth не уверен, но на мой
> взгляд не должно быть проблем.
>
>> Надо с этим чего-то придумать на верхнем уровне make-initrd. Некий общий
>> аналог console-sh-functions, через API которого можно будет избежать
>> гонок и конфликтов при инициализации консолей.
> Я пока не понял сути проблемы.

Для апстрима bootchain/altboot проблемы нет. Даже не идеальную 
bootchain-interactive можно заппстримить сейчас "как есть", а потом её 
улучшать, переводить с openvt на screen или tmux.

Проблема, если мы хотим превратить bootchain-interactive в 
interactive/pseudogui или как-то ещё, сделав независимой от bootchain, 
получить фичу для работы с диалогами, которую смогут использовать и 
другие фичи, и которая сама будет нормально взаимодействовать с такими 
фичами, использующими (ломающими) консоль, как plymouth или kbd.

Вот это уже твой уровень: надо подумать, как в make-initrd можно 
обеспечить совместную работу:

1) Нескольким фичам с любым произвольным ttyN;
2) Нескольким фичам с неким диалоговым TTY.

Мы это хотели обсудить очно...


-- 
Best regards,
Leonid Krivoshein.