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

[Alexey Gladkov]

On Wed, Apr 07, 2021 at 02:13:39AM +0300, Leonid Krivoshein wrote:
> 
> 06.04.2021 22:30, Alexey Gladkov пишет:
> > On Tue, Apr 06, 2021 at 09:05:32PM +0200, Alexey Gladkov wrote:
> > > > > > 5. Исходная идея pipeline -- организовать цепочку с входом и выходом у
> > > > > > каждого элемента. А как быть в ситуациях, когда ты заказал дождаться 4х
> > > > > > устройств?
> > > > > pipeline=waitdev,waitdev,... \
> > > > > 	waitdev=/dev/cdrom \
> > > > > 	waitdev=/dev/sda
> > > > > 
> > > > > Это обсуждалось и исправлялось [1]. У любого шага есть начало и конец, но
> > > > > не обязательно, что на выходе должно быть что-то, что будет монтироваться.
> > > > > Это может быть шаг с диалоговым окном для корректировки поведения
> > > > > следующих шагов.
> > > > Хорошо, дождались нескольких устройств. Выход получили только от последнего.
> > > Да нет же. Ты получаешь доступ ко _всем_ предыдущим шагам. Ты можешь к ним
> > > обращаться pipeN, N это номер шага.
> > Я знаю, что тут много моей вины. Я не задокументировал это должным
> > образом. Я своё оправдание скажу, что год это никто даже не пробовал
> > использовать.
> > 
> > Но посмотри на реализацию шага overlayfs. Я специально его сделал для
> > иллюстрации того, что возможно использовать несколько предыдущих шагов.
> 
> В коде-то я увидел, потому и спросил в предыдущем письме: Как написать
> универсальный шаг, который обработает результаты нескольких предыдущих?
> Передавать этому шагу номера pipe'ов через cmdline? Что ты ниже и
> предлагаешь:

Можно передавать через cmdline, да. Именно можно, а можно и не передавать.

> 
> > В overlayfs параметр если указан это список того, что будет lowerdir. Для
> > каждого элемента используется resolve_target, которая либо берёт что
> > укажешь, либо если это pipeN вернёт dst этого шага. Таким образом ты
> > можешь указать overlayfs=pipe1,pipe2,pipe3 и собрать три шага в свой dst.
> 
> Пользователь может редактировать cmdline, такой интерфейс я бы не назвал
> безопасным, интуитивно понятным и простым.

Во-первых не всегда может. Ещё во времена lilo уже можно было этим
управлять.

Во-вторых может и что ? Если пользователь имеет доступ к cmdline он может
изменить init=, root=. Давай защищаться от реальных угроз, а не
вымышленных.

Сам initramfs immutable и cmdline это способ указать динамическую
конфигурацию. Интерфейс конфигурации pipeline позволяет сконфигурировать
initramfs, загруженный через PXE например. При этом не нужно создавать
разный набор initramfs под разные конфигурации.

> Нужно хорошо понимать работу pipeline, мысленно переводить строку
> kw1,kw2,kw3,... в массив, производить в уме сдвиги ячеек в нём,
> прописывать в cmdline новые индексы, и конечно молиться, чтобы ничего не
> сломалось. :-)

Прости, это не аргумент. Для правильного указания root= нужно знать UUID
или LABEL рутового устройства, для указания других параметров ядра нужно
знать как они повлияют на ядро.

cmdline это системный интерфейс и требует определённой квалификации.

Если у пользователя возникла задача, для которой создан pipeline, то я
уверен в том, что cmdline параметры pipeline меньшая его проблема.

> Проблему распараллеливания и синхронизации цепочек это тоже не решает. А
> ведь что такое pipeline, когда уже есть event-driven механизм, если не
> "ручное" управление порядком загрузки плюс возможность смешивать эти два
> подхода?

Ты всегда упоминаешь некое распараллеливание, но нигде его не описывал.

У меня в голове есть одна схема, где фигурирует слово "распараллеливание",
но я почти уверен, что это не то, что ты имеешь в виду.

-- 
Rgrds, legion