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

[Alexey Gladkov]

On Mon, Jun 28, 2021 at 07:34:02PM +0300, Leonid Krivoshein wrote:
> 
> 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'ом её тоже можно решать достаточно надёжно. Если
> оставить как сейчас -- не будет лишней зависимости.

Я не в плане делать stty а в плане вычисления rows и cols.

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

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

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

Есть ещё одна система, которая меньше требует и которая больше мне
нрафится - kconfig. Я правда не уверен, что она будет покрывать 100% нужд.
Нужно смотреть.

-- 
Rgrds, legion