Make-initrd development discussion
 help / color / mirror / Atom feed
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: make-initrd@lists.altlinux.org
Subject: Re: [make-initrd] make pseudo GUI from bootchain-interactime common feature
Date: Tue, 29 Jun 2021 01:38:37 +0200
Message-ID: <20210628233837.qavhgeecgozv3oid@example.org> (raw)
In-Reply-To: <afb78d2a-7edc-3d64-8a9b-c9a56705f906@gmail.com>

On Mon, Jun 28, 2021 at 10:43:20PM +0300, Leonid Krivoshein wrote:
> > > Нет, имел ввиду весь bootchain. И даже более широко. Было бы хорошо в самом
> > > make-initrd иметь наряду с параллельной событийно-ориентированной обработкой
> > > интерфейс, позволяющий выполнять что угодно последовательно, не только с
> > > диалогами. pipeline/bootchain эту задачу решают, но возможно на уровне
> > > интерфейса make-initrd её можно решить ещё лучше, а bootchain со своими
> > > "входами" и "выходами" сделать частным использованием этого общего
> > > интерфейса make-initrd. Некоторые вещи нужно обрабатывать последовательно, а
> > > не как карта ляжет. Например resume, fsck, создание оверлеев...
> > Для общесистемного применения нужны usecases, иначе такой функционал будет
> > лежать мёртвым грузом. Если же этот функционал нужен лишь иногда, то для
> > этого есть фичи.
> 
> Конечно, но несколько штук перечислил. Мне-то не видно всех возможностей
> make-initrd, поэтому со своей колокольни для решения конкретных задач сходу
> пришло два варианта реализации: 1) перетащить названные фичи в bootchain или
> сделать зависимыми от него; 2) сделать в bootchain дубликаты этих фич. Тогда
> можно чётко выстраивать в цепочку: проверили диск fsck, проснулись, если это
> resume, построили оверлей над обычной rootfs. Т.е. речь не о диалогах, а о
> синхронизации, последовательном выполнении.

Никакое последовательное выполнение не поможет тебе с resume и fsck. Такой
подход уже был в mkinitrd и он даже там не работал нормально. Swap может
находиться не на разделе или диске (спасибо фантазии пользователей), а на
raid, lvm и/или luks. Даже если и на разделе, то тебе нужно дождаться
инициализации _всех_ дисков, которые это делают с разной скоростью. В
любой момент времени ты просто не можешь знать все ли диски
проинициализировались. Пока всё не проининициализируется ты не можешь быть
уверен, что в T+1 не появится раздел с swap, на котором будет сигнатура
hibernate.

И уж тем более тебе это не поможет с fsck, потому что диски будут
появляться, а потом в конце появится диск с swap и сигнатурой hibernate.
У тебя будет всё та же дилемма: проверять диски или же ждать пока не
проинициализируются все диски (сколько ждать?).

Проблема resume не решается "последовательным выполнением".

Единственный выход, который мне видится с resume это заранее запомнить
swap'ы и подождать их и проверить.

Так что я не согласен с этими перечисленными юскейсами. Я не вижу иного
применения bootchain, кроме как для случаев не связанных с локальным
железом... ну почти.

> Сейчас, если в bootchain шаг ничего не принимает на входе и не передаёт
> на выходе, он вызывает bypass_results(), связывая выход предыдущего шага
> со входом следующего.  Расходуется при этом лишний каталог в tmpfs.

Ты экономишь один dentry в tmpfs ? Да будь из хоть 100 ты не сможешь
переплюнуть libcrypto, которая занимает 2,9M. Ты экономишь совсем не то.

Кроме того, мне кажется, что можно обойтись и без этого лишнего создания.

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

-- 
Rgrds, legion



  reply	other threads:[~2021-06-28 23:38 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
2021-06-28 18:48         ` Alexey Gladkov
2021-06-28 19:43           ` Leonid Krivoshein
2021-06-28 23:38             ` Alexey Gladkov [this message]
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=20210628233837.qavhgeecgozv3oid@example.org \
    --to=gladkov.alexey@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