From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 29 Jun 2021 01:38:37 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210628233837.qavhgeecgozv3oid@example.org> References: <1624543840.397742661@f474.i.mail.ru> <20210628140143.m7r7ocn67kgagedj@example.org> <20210628160624.gglemxc5st6ucqog@example.org> <3d683f36-0115-499b-6815-7b8d561e3351@gmail.com> <20210628184857.dta2grbb3hma6b7k@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] make pseudo GUI from bootchain-interactime common feature 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: Mon, 28 Jun 2021 23:38:39 -0000 Archived-At: List-Archive: 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