Make-initrd development discussion
 help / color / mirror / Atom feed
From: Leonid Krivoshein <klark.devel@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] make pseudo GUI from bootchain-interactime common feature
Date: Mon, 28 Jun 2021 19:34:02 +0300
Message-ID: <3d683f36-0115-499b-6815-7b8d561e3351@gmail.com> (raw)
In-Reply-To: <20210628160624.gglemxc5st6ucqog@example.org>


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.



  reply	other threads:[~2021-06-28 16:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 14:01 ` Alexey Gladkov
2021-06-28 14:43   ` Leonid Krivoshein
2021-06-28 16:06     ` Alexey Gladkov
2021-06-28 16:34       ` Leonid Krivoshein [this message]
2021-06-28 18:48         ` Alexey Gladkov
2021-06-28 19:43           ` Leonid Krivoshein
2021-06-28 23:38             ` Alexey Gladkov
2021-06-29  0:50               ` Leonid Krivoshein
2021-06-29  8:28                 ` Alexey Gladkov
2021-06-28 16:39       ` Leonid Krivoshein
2021-08-22 13:09       ` Leonid Krivoshein
2021-06-28 15:57   ` Leonid Krivoshein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d683f36-0115-499b-6815-7b8d561e3351@gmail.com \
    --to=klark.devel@gmail.com \
    --cc=make-initrd@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Make-initrd development discussion

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \
		make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com
	public-inbox-index make-initrd

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.make-initrd


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git