[make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1

[Alexey Gladkov]

On Tue, Apr 06, 2021 at 08:38:27PM +0300, Leonid Krivoshein wrote:
> 
> 06.04.2021 11:44, Alexey Gladkov пишет:
> > On Tue, Apr 06, 2021 at 01:51:30AM +0300, Leonid Krivoshein wrote:
> > > 8. Можно сделать общее описание входа/выхода для всех поддерживаемых шагов и
> > > выполнять необходимые проверки до и после выполнения шага, чтобы не не
> > > делать этого внутри самих шагов. Такое описание будет полезно и для шага
> > > debug. Шаги могут быть транзитными (pass-thru).
> > Я не хочу навязывать что должны шага принимать и уж тем более нельзя
> > навязывать, что они должны возвращать. Например, waitdev ничего не
> > монтирует т.е. на выходе нет ничего кроме задержки перед следующим шагом.
> > 
> > Могут быть шаги, которые будут спрашивать что-то у пользователя. Описывать
> > такое очень сложно.
> 
> Можно сделать необязательным описание входа. Если не описано, считать, что
> на входе может быть что угодно и задача шага -- проверить это самостоятельно
> и вывести fatal(). Если же есть описание, проверку может делать сам
> pipeline. ANY -- что угодно, DEV -- устройство, DIR -- каталог, PASS -- шаг
> не обрабатывает вход, вместо этого он должен быть напрямую связан с выходом
> без обработки, т.е. в данном случае pipeline должен передать выход
> предыдущего шага на вход следующего шага или первого, который не PASS.
> 
> Иначе каждый шаг начинается с проверок и вывода fatal(), а в конце сейчас
> приходится использовать специально написанную для данного случая
> pass_thru_pipeline(). Именно эту однотипную и примитивную обработку
> предлагаю перетащить в pipeline, чтобы не делать её на каждом шаге.

Я в принципе не против перераспределения обязанностей между шагами и
pipelined. Но я считаю, что децентрализация лучше. Сейчас шаги
предоставлены себе. Они могут быть написаны на bash, на си, на lua.
Демону это не важно. Он лишь отвечает за несколько простых вещей:

1. подготовить директории для данных шага и для результата.
2. запустить программу шага и проконтролировать код возврата.

Он обменивается с шагами только 5ю переменными окружения, которые можно
обработать на любом языке. Остальное шаги делают сами.

Если хочется автоматизировать получение параметра для bash, то можно
написать common-script, который будет сорсится в шагах и который будет
делать:

check_parameter PARAM
param="$(get_parameter PARAM)"

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

-- 
Rgrds, legion