From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 7 Apr 2021 15:13:27 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210407131327.tblzuljdgbbsgrbe@example.org> References: <53056ce2-d0bd-dcab-880f-80f2a6b6892a@gmail.com> <20210406084450.rxggsmhapka7g6lo@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [make-initrd] Fwd: [#269003] TESTED make-initrd.git=2.14.1-alt1 X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 13:13:29 -0000 Archived-At: List-Archive: 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