[make-initrd] make pseudo GUI from bootchain-interactime common feature

[Leonid Krivoshein]

28.06.2021 19:06, Alexey Gladkov пишет:
> On Mon, Jun 28, 2021 at 05:43:48PM +0300, Leonid Krivoshein wrote:
>>> [...]
>>> Леонид, а у тебя какие планы на bootchain-interactive ?
>> Планы -- как можно быстрее интегрировать всю связку в make-initrd.
>>
>> Идея переместить bootchain-interactive на верхний уровень и сделать частью
>> make-initrd, независимой от bootchain была с самого начала, поэтому весь код
>> этой фичи так написан, что он совсем не зависит от других модулей bootchain.
>> Есть, правда, пара "но". Именно bootchain-interactive, как концепция,
>> создана наспех, для написания остального кода altboot, поэтому её хорошо бы
>> поревьювить именно в части общей пригодности интерфейса и арифметики.
> Ну это не проблема.
>
> Кстати, однажды Олег Нестеров подсказал мне вот такой код:
>
> ttysz()
> {
> 	local esc cols rows
> 	echo -ne "\e[s\e[1000;1000H\e[6n\e[u"
> 	IFS=';[' read -s -t2 -dR esc rows cols ||
> 		{ echo >&2 'ttysz() FAILED'; return 0; }
> 	stty rows $rows cols $cols
> }
>
> Думаю, что его можно модифицировать и использовать для твоих нужд.

Для определения размеров TTY и для сохранения/восстановления консоли в 
первых реализациях я тоже использовал stty. Но потом обнаружил, что 
сохранение/восстановление поддерживается далеко не всеми TTY, поэтому 
использовал отдельную консоль, которую просто чищу за собой, а 
определение размера не проблема, dialog'ом её тоже можно решать 
достаточно надёжно. Если оставить как сейчас -- не будет лишней зависимости.


>> Второй момент куда более важный. bootchain (изначально pipeline) мне видится
>> как решение проблемы синхронизации последовательности выполняемых действий
>> независимо от последовательности входящих событий. Так, фича overlayroot в
>> bootchain сейчас может "гоняться" с фичей "resume" make-initrd. С ней вообще
>> много чего может "гоняться".
> Я специально не трогал pipeline, чтобы не ломать тебе ничего. Я решал
> примерно такую же проблему с kickstart. На время работы таких фич как
> kickstart и pipeline нужно выключать обработку эвентов в ueventd. Но не
> всех, а только тех, что отвечают за разбор того, что пришло из udev.
>
> Это реализовано в kickstart. Перед запуском kickstart ставит на паузу
> очередь udev и снимает с паузы после обработки сценария (если управление
> возвращается initramfs). Насколько это хорошее решение пока не знаю, но
> это работает.
>
> Примерно это же можно делать и в bootchain т.е. блокировать обработку
> очереди udev эвентов при заходе в условный main_loop.
>

Интересно, надо будет посмотреть повнимательней.


>> Было бы здорово сделать весь bootchain частью
>> интерфейса make-initrd, и чтобы код разных его фич можно было более тесно
>> интегрировать с bootchain, при необходимости. В первую очередь network, да и
>> всё, что можно конфигурировать через диалоги, запрос паролей не только на
>> токены, но и crypto-luks. Но это такие мечты и отдалённые задачи, наверняка
>> решаемые уже после того, как удастся заапстримить bootchain.
> Ты наверно имел в виду не весь bootchain, а фичу с диалогами ?

Нет, имел ввиду весь bootchain. И даже более широко. Было бы хорошо в 
самом make-initrd иметь наряду с параллельной событийно-ориентированной 
обработкой интерфейс, позволяющий выполнять что угодно последовательно, 
не только с диалогами. pipeline/bootchain эту задачу решают, но возможно 
на уровне интерфейса make-initrd её можно решить ещё лучше, а bootchain 
со своими "входами" и "выходами" сделать частным использованием этого 
общего интерфейса make-initrd. Некоторые вещи нужно обрабатывать 
последовательно, а не как карта ляжет. Например resume, fsck, создание 
оверлеев...


> Мне сразу в голову пришло примерно как это сделано в dpkg-configure. У нас
> же примерно такая же задача. У нас есть параметры, которые могут быть
> заданы, если нет, то о них нужно спросить или же использовать некие
> дефолты если возможно. Нужно будет поизучать как это у них уже
> реализовано.

Да, классная идея, но это уже следующий уровень интеллекта. Не уверен, 
что сходу достижимый, по крайней мере, без изменения интерфейса 
регистрируемых аргументов make-initrd. Но если отталкиваться не от 
параметров make-initrd, а от того, как данные описываются в d-i 
(dpkg-configure использует эту модель, если не ошибаюсь), то да, но 
скорее всего диалоги там не автоматически формируются, а тоже используют 
библиотеку доступа к этим данным. Давно изучал вопрос, поэтому плохо 
помню, что там и как.


>> При написании документации (уже около 30 страниц) обнаружил пару
>> архитектурных изъяна в bootchain и сейчас их уже почти исправил, но пока не
>> выгрузил обновления. При этом добился полной совместимости с pipeline, для
>> его пользователей теперь вообще ничего можно не менять. С ipmi/novga
>> консолями и utf8 тоже пока остаётся вопрос, как решать, ещё не заходил на
>> эту задачу. И останется всё ещё раз прогнать на стендах, так-то оно вроде
>> работало. После этого можно переходить к движению в апстрим в твоим
>> участием! :-)
> Ok. Нет проблем :)
>

-- 
Best regards,
Leonid Krivoshein.