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] [PATCH v6 08/22] bootchain-waitdev: introduces an optional waitdev_timeout
Date: Sat, 6 Nov 2021 17:39:10 +0300
Message-ID: <7c5ab56f-e0d3-c48c-6ee6-02f47ed3f33b@gmail.com> (raw)
In-Reply-To: <20211106131130.zvwsnnikmaq7oqmz@example.org>


06.11.2021 16:11, Alexey Gladkov пишет:
> On Tue, Oct 26, 2021 at 10:31:58PM +0300, Leonid Krivoshein wrote:
>>>> А как происходит этот fallback ?
>>>>
>>>> В твоей реализации если достигнут таймаут, то последующие waitdev просто
>>>> exit 0 делают и невозможно понять дождались они чего-то или нет.
>>>>
>>>> Получается, что следующий шаг может только гадать о результате waitdev.
>>>>
>>>> Потому что мне сейчас приходит в голову сделать параметр (или шаг)
>>>> onfail, но это явно не то чем пользуешься ты для failback.
>>> Ох. Ты спрятал его в 16 патче в next_bootchain. Но тогда у меня всё равно
>>> вопрос, как будет происходить fallback если next_bootchain waitdev не
>>> вызывает ?
>> Без вызова next_bootchain и многоходовочки:
>>
>> waitdev,waidev,localdev waitdev_timeout=7 waitdev=... waitdev=...
>> altboot_localdev=...
>>
>> Имеем два wiatdev, один localdev и общий таймаут на все waitdev'ы.
>>
>> Если первый или второй waidev не уложатся в 7 секунд, т.е. если за заданное
>> время не будет найдено всех заданных устройств waitdev, не тормозим, а
>> переходим к следующему шагу localdev. В этом суть fallback'а и общего
>> таймаута. localdev может проверить результат предыдущего шага, ему
>> достаточно проверить только последний waitdev.
> Леонид, но это же чёрная магия. Получается неявное использование timeout и
> расчёт на отсутствие результата у последнего waitdev.

timeout_waitdev=... в /proc/cmdline задаётся вполне себе явно. И если не 
задаётся, то и не используется. Логика к тому же также явно определяет 
общее поведение: мы даём некоторое время на отработку всех вместе взятых 
waitdev'ов, но если что-то пойдёт не так, то переходим к сканированию 
устройств или выбору их в диалоге. Как раз тут никакой магии.


> Кроме того, получается, что нужно всё время держать в голове такую
> особенность, а также, что только localdev проверяет предыдущий шаг.

На самом деле любой шаг может передавать следующему какой-то результат 
работы. И если мы не хотим, чтобы следующий шаг его использовал, 
необходимо вставить специальный разделитель в цепочку -- внутренний шаг 
"noop". Всё это было сделано для обеспечения возможности объединения 
двух плохо стыкуемых концепций -- pipeline и propagator.


> Хотя, это детали реализации шага и если это исправлять, то мы перейдём к
> метапрограммированию в cmdline. Я не знаю, что лучше ((

Моё предложение заключалось в том, чтобы добавить префикс TIMEOUT=... 
для конкретного шага, если в нём тоже есть польза, но не убирать общий 
waitdev_timeout=..., чтобы оставить возможность отрабатывать fallback, 
как сказано в описании. Иначе придётся отказываться от нескольких 
коммитов вокруг bootchain-waitdev, тогда состыковать шаги waitdev и 
altboot окажется невозможно, каждый будет сам по себе.


-- 
Best regards,
Leonid Krivoshein.



  reply	other threads:[~2021-11-06 14:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 10:55 ` Alexey Gladkov
2021-10-26 11:25   ` Leonid Krivoshein
2021-10-26 13:55     ` Alexey Gladkov
2021-10-26 14:05       ` Alexey Gladkov
2021-10-26 19:31         ` Leonid Krivoshein
2021-11-06 13:11           ` Alexey Gladkov
2021-11-06 14:39             ` Leonid Krivoshein [this message]
2021-11-06 14:55               ` Alexey Gladkov
2021-10-26 18:13       ` 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=7c5ab56f-e0d3-c48c-6ee6-02f47ed3f33b@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