[make-initrd] I: ncurses experiment

[make-initrd] I: ncurses experiment

[Alexey Gladkov]

Привет!

Я попробовал поэкспериментировать с текстовыми диалогами. Я держал в
голове встраиваемые системы и make-initrd.

Если использовать обычный в таких случаях dialog(1), то разным скриптам,
его использующим, необходимо договариваться кто в данный момент владеет
терминалом. Проблема усугубляется, если у системы serial или netconsole.

Можно использовать screen/tmux для переключения клиентов терминала, но у
этих мультиплексеров не всегда удобный API для переключений клиентов. Плюс
приходится всё-равно думать кого в данный момент показывать.

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

Скрипт может послать запрос на создание диалога и либо заблокироваться и
ожидать результат, либо продолжить заниматься своими делами и проверять
состояние диалога.

Диспетчер же берёт на себя сериализацию запросов (т.к. ncurses не
поддерживает multithreads), переключение фокуса между диалогами,
переключение пользовательского ввода, сохраняет и возвращает клиенту
состояние диалогов.

В принципе, это у меня получилось. Есть диспетчер и диалоги в виде
плагинов. Есть немного документации и тестов.

https://github.com/osboot/plainmouth

-- 
Rgrds, legion

Re: [make-initrd] I: ncurses experiment

[Alexey Gladkov]

On Tue, Dec 23, 2025 at 02:53:21PM +0100, Alexey Gladkov wrote:
> Привет!
> 
> Я попробовал поэкспериментировать с текстовыми диалогами. Я держал в
> голове встраиваемые системы и make-initrd.
> 
> Если использовать обычный в таких случаях dialog(1), то разным скриптам,
> его использующим, необходимо договариваться кто в данный момент владеет
> терминалом. Проблема усугубляется, если у системы serial или netconsole.
> 
> Можно использовать screen/tmux для переключения клиентов терминала, но у
> этих мультиплексеров не всегда удобный API для переключений клиентов. Плюс
> приходится всё-равно думать кого в данный момент показывать.
> 
> Я подумал, что можно упростить жизнь, если сделать диспетчер, который
> владел бы терминалом и параллельно отображал бы диалоги по запросам
> скриптов.
> 
> Скрипт может послать запрос на создание диалога и либо заблокироваться и
> ожидать результат, либо продолжить заниматься своими делами и проверять
> состояние диалога.
> 
> Диспетчер же берёт на себя сериализацию запросов (т.к. ncurses не
> поддерживает multithreads), переключение фокуса между диалогами,
> переключение пользовательского ввода, сохраняет и возвращает клиенту
> состояние диалогов.
> 
> В принципе, это у меня получилось. Есть диспетчер и диалоги в виде
> плагинов. Есть немного документации и тестов.
> 
> https://github.com/osboot/plainmouth

Я несколько продвинулся в этом эксперименте. Я сделал плагины, чтобы
создавать достаточно сложные интерфейсы. Теперь у меня есть аналог
dialog(1) для некоторой совместимости.

Я надеюсь попробовать сделать фичу для вывода диалогов через plainmouth.
Надеюсь найду время.

-- 
Rgrds, legion

Re: [make-initrd] I: ncurses experiment

[Leonid Krivoshein]

Привет!


On 10/16/26 5:20 PM, Alexey Gladkov wrote:
> On Tue, Dec 23, 2025 at 02:53:21PM +0100, Alexey Gladkov wrote:
>> Привет!
>>
>> Я попробовал поэкспериментировать с текстовыми диалогами. Я держал в
>> голове встраиваемые системы и make-initrd.
>>
>> Если использовать обычный в таких случаях dialog(1), то разным скриптам,
>> его использующим, необходимо договариваться кто в данный момент владеет
>> терминалом. Проблема усугубляется, если у системы serial или netconsole.
>>
>> Можно использовать screen/tmux для переключения клиентов терминала, но у
>> этих мультиплексеров не всегда удобный API для переключений клиентов. Плюс
>> приходится всё-равно думать кого в данный момент показывать.
>>
>> Я подумал, что можно упростить жизнь, если сделать диспетчер, который
>> владел бы терминалом и параллельно отображал бы диалоги по запросам
>> скриптов.
>>
>> Скрипт может послать запрос на создание диалога и либо заблокироваться и
>> ожидать результат, либо продолжить заниматься своими делами и проверять
>> состояние диалога.
>>
>> Диспетчер же берёт на себя сериализацию запросов (т.к. ncurses не
>> поддерживает multithreads), переключение фокуса между диалогами,
>> переключение пользовательского ввода, сохраняет и возвращает клиенту
>> состояние диалогов.
>>
>> В принципе, это у меня получилось. Есть диспетчер и диалоги в виде
>> плагинов. Есть немного документации и тестов.
>>
>> https://github.com/osboot/plainmouth
> 
> Я несколько продвинулся в этом эксперименте. Я сделал плагины, чтобы
> создавать достаточно сложные интерфейсы. Теперь у меня есть аналог
> dialog(1) для некоторой совместимости.
> 
> Я надеюсь попробовать сделать фичу для вывода диалогов через plainmouth.
> Надеюсь найду время.
> 

Пока в Сизиф не опакечено и нет примера-фичи, не очень понятно. По 
документации юскейс тоже не очень понятен. Сложно представить себе 
несогласованные скрипты из разных фич make-initrd, выводящие разные 
диалоги на единственный терминал, с нагромождением которых придётся 
разбираться пользователю.

Кода для разделения единственного терминала /dev/console через tmux на 
разные сессии в качестве замены TTY сейчас в основной ветке не вижу, 
есть наброски в отдельных ветках, типа use-tmux [1].

Как мы говорили раньше, хотелось бы замены bootchain-interactive [2] на 
уровне всего make-initrd. Конечно, с удобными диалогами, когда можно 
обходиться без параметров, которые и так легко вычислить.

Мне понятна концепция "своя сессия на каждую фичу, у которой есть ввод 
данных от пользователя либо есть вывод прогресса длительно выполняющихся 
процессов". При пошаговой загрузке диалоги открываются последовательно. 
Для аварийной консоли rdshell -- свой сеанс, для вывода статусов демонов 
(/dev/console) -- свой, для общего лога демонов, если нужно, третий сеанс.

Если какой-то фиче потребовалось вывести диалог ввода (например, пароль 
на LUKS), её tmux-сессия становится активной, а сразу после ввода фича 
может вернуть фокус ввода или это сделает make-initrd при завершении 
tmux-сессии этой фичи. В bootchain-interactive отложенная на 8 секунд 
активация диалогового TTY и немедленная, если возникает диалог ввода.

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


Ссылки:

1. 
https://github.com/osboot/make-initrd/commit/817d9ed89f39a8ead233af9b3d5a5bfa170037b0
2. 
https://github.com/klark973/make-initrd-bootchain/blob/sisyphus/bootchain-interactive/README.md


-- 
WBR, Leonid Krivoshein.

Re: [make-initrd] I: ncurses experiment

[Alexey Gladkov]

On Sat, Oct 17, 2026 at 01:22:06AM +0300, Leonid Krivoshein wrote:
> > Я несколько продвинулся в этом эксперименте. Я сделал плагины, чтобы
> > создавать достаточно сложные интерфейсы. Теперь у меня есть аналог
> > dialog(1) для некоторой совместимости.
> > 
> > Я надеюсь попробовать сделать фичу для вывода диалогов через plainmouth.
> > Надеюсь найду время.
> > 
> 
> Пока в Сизиф не опакечено и нет примера-фичи, не очень понятно. По
> документации юскейс тоже не очень понятен. Сложно представить себе
> несогласованные скрипты из разных фич make-initrd, выводящие разные диалоги
> на единственный терминал, с нагромождением которых придётся разбираться
> пользователю.

Да, я знаю, что ты не понимаешь моей задумки :) Я написал для самоотчета и
для подписчиков, которых ещё не знаю. В друг кого-нибудь заинтересует.

Но твой bootchain-interactive делает тоже самое. Он рисует диалоги из
разных мест скрипта.

plainmouth сведёт всё на один экран и даст более удобный способ
реагировать на события в диалоге. Он не избавит от необходимости
синхронизации между скриптами.

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

Я постарался покрыть plainmouth тестами. Некоторые из них можно запускать
интерактивно.

> Кода для разделения единственного терминала /dev/console через tmux на
> разные сессии в качестве замены TTY сейчас в основной ветке не вижу, есть
> наброски в отдельных ветках, типа use-tmux [1].
> 
> Как мы говорили раньше, хотелось бы замены bootchain-interactive [2] на
> уровне всего make-initrd. Конечно, с удобными диалогами, когда можно
> обходиться без параметров, которые и так легко вычислить.
> 
> Мне понятна концепция "своя сессия на каждую фичу, у которой есть ввод
> данных от пользователя либо есть вывод прогресса длительно выполняющихся
> процессов". При пошаговой загрузке диалоги открываются последовательно. Для
> аварийной консоли rdshell -- свой сеанс, для вывода статусов демонов
> (/dev/console) -- свой, для общего лога демонов, если нужно, третий сеанс.
> 
> Если какой-то фиче потребовалось вывести диалог ввода (например, пароль на
> LUKS), её tmux-сессия становится активной, а сразу после ввода фича может
> вернуть фокус ввода или это сделает make-initrd при завершении tmux-сессии
> этой фичи. В bootchain-interactive отложенная на 8 секунд активация
> диалогового TTY и немедленная, если возникает диалог ввода.
> 
> Такой подход позволяет избежать ненужного мелькания чего-либо про
> загружаемые процессы, если это происходит довольно быстро. В то же время,
> ошибки или ввод данных требует немедленного внимания. Если внимание
> потребуется двум и более не связанным фичам, не вижу проблем передавать
> фокус в очерёдности, обратной поступлению запросов.
> 
> 
> Ссылки:
> 
> 1. https://github.com/osboot/make-initrd/commit/817d9ed89f39a8ead233af9b3d5a5bfa170037b0
> 2. https://github.com/klark973/make-initrd-bootchain/blob/sisyphus/bootchain-interactive/README.md
> 
> 
> -- 
> WBR, Leonid Krivoshein.
> 
> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd

-- 
Rgrds, legion