Re: [make-initrd] udhcpc script в фиче network

[Alexey Gladkov <gladkov.alexey@gmail.com>]

On Thu, Sep 23, 2021 at 01:06:33AM +0300, Leonid Krivoshein wrote:
> > Ты где-то отдельно пишешь код
> 
> Код отправляю пока в Сизиф и в локальную гитовницу:
> 
> git.altlinux.org/people/klark/packages/make-initrd-bootchain.git

Это отдельный репозиторий, делать ревью коммитов непонятно как.
git.alt/people это почти худшее место для обсуждения хода. Даже тарболл и
патчи в рассылке лучше.

Ты несколько раз говорил про него, но я просто не знаю, что с ним делать.

Я уже понял, что этот репозиторий живёт своей жизнью и имеет свою историю
изменений. Эта история безусловно важна и выкидывать её будет ошибкой. Но
проблема в том, что я не представляю как это мерджить поскольку это даже
как subtree сделать.

Моё предыдущее предложение сделать патчсет уже не актуально в данной
ситуации. Я предполагал, что у тебя будет некая минимальная реализация, а
остальное мы доработали бы в рабочем порядке. В этом случае все изменения
бы ли бы рабочими и проходили обсуждение. Увы, это всё теперь невозможно.

Но ты выбрал иную стратегию. Ты разрабатываешь вещь в себе в отдельном
репозитории. Это просто некое отдельное решение на основе make-initrd.

Этот репозитории повторяет стратегию make-initrd-propagator, который
как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в
себе. Новый, правда, интегрирован с основным кодом лучше.

> > вместо того чтобы обсуждать и порциями добавлять.
> 
> Если бы работы по обсуждённому ранее плану были завершены, мне бы только и
> оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам
> настаивал, чтобы продукт был тщательно проверен до того, как он поедет в
> апстрим. Находятся замечания, предложения, приходится их устранять и
> учитывать. А из-за этого у меня откладывается работа по автоматизации
> тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно
> работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать
> очередные регулярки с разными опциями и методами загрузки.
> 
> Лично мне кажется, что ни один пакет у нас так пристально не проверялся,
> попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и
> моя задача учесть совместимость с уже сделанным в Альте за многие годы.

Я начинаю думать, что уже лучше оставить всё как есть сейчас. Пусть
make-initrd-bootchain остаётся отдельным репозиторием и пакетом.

Когда в make-initrd будут появляться новые интерфейсы или фичи, то они
будут начинать использоваться в make-initrd-bootchain. В том числе, когда
какой-то функционал будет переползать в апстрим.

Иначе я просто не представляю как всё уже написанное поддерживать.

> > Ты уже спроектировал и реализовал свою систему так с чем я не
> > могу согласиться.

> мы решаем задачу по избавлению от propagator и запихиванию
> его функционала в make-initrd. Всё это проделано зря, если вместо propagator
> предложить в чистом виде pipeline или иную новую концепцию загрузки, которая
> будет идеальной с точки зрения make-initrd

Так. Очень интересно, но об этом чуть ниже.

> Как раз я старался учесть возможность перехода в будущем на более правильные
> концепции. Но сейчас и тебе надо принять, как данность, что пусть
> "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был
> внутри make-initrd

Вот тут ты ошибаешься. Мне не нужно и тебе не советую принимать как
данность, что нужно повторять поведение, которое написано в 2004. Это
поведение чуть-чуть устарело.

Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем
его переизобретать.

> и работал как 1/80 часть его рантайма, а не наоборот,
> чтобы настоящий propagator полностью выкидывал и заменял собой все 100%
> рантайма make-initrd.

Признаюсь тебе: мне нет дела до propagator. Это древний кусок гов^W кода.
Раньше он замечательно работал без make-initrd. Он делает всё сам и своими
методами.

Считаю ли я, что _функционал_ propagator может быть реализован на
make-initrd ? Да.

Считаю ли я, что поведение propagator нужно воспроизводить ? Нет.

Я считаю, что должна быть сохранена совместимость до определённой степени.
Я не считаю, что нужна полная копия поведения. Для последнего у вас есть
сам propagator.

> Можно и нужно обсуждать, как лучше сделать это, не
> ломая совместимости, и учитывая потребности перехода на что-то более
> правильное в перспективе.

Ты сам себе противоречишь. Я должен принять, как данность функционал
пропагатора и не ломая совместимости с кодом 17 летней (на самом деле
большей) давности переходить на что-то более правильное.

И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить
с и переписывать эту "данность" с учётом совместимости буду я ? Отличная
перспектива.

А давайте сначала вы осознаете, что вам не нужен клон propagator и будете
апстримить уже стазу более правильное ?

Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так,
что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на
поддержку.

> > И я до сих пор не видел ни одного патча. Поэтому для
> > меня каждая твоя проблема является большим сюрпризом.
> 
> Кажется, несколько попыток я уже делал, в частности, отдельно предлагал
> bootchain-interactive.

Патчей или PR так и не было.

А каталог bootchain-interactive в упомянутом выше репозитории ничем в
make-initrd не используется. Все сообщения make-initrd идут мимо. Кроме
того, мы уже обсуждали использование других vt.

Я не очень понимаю, что делать с этой фичей в make-initrd-bootchain.git

> Но, как я понял, ты хочешь принять всё одним разом, и
> только после тщательной проверки всей связки. Так мы этой проверкой сейчас
> занимаемся.

Я хотел совсем не этого. См. выше.

> После этого мне ещё README для каждой фичи писать и только потом
> делать коммиты в апстрим -- таков был план.

Не. Этот поезд уже ушёл. Превращать репозиторий с историей изменений в
некий патчет просто не имеет смысла.

> > Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у
> > тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp
> > нужно аккуратно остановить.
> 
> В текущей простой ситуации, которую нельзя назвать финальным/идеальным
> вариантом, у пользователя нет шансов что-либо захотеть. :-)

Так это неправильно. Пользователь может такое хотеть. Да и дело не только
в dhcp -> static. Нужно уметь расконфигурировать интерфейс.

> http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=5a1a8d2acd09c06d8091b921803850ea313de2ed;hb=9305bcd041b50b018d7fa4c11cebac4123514b26#l24

> if [ ! -s /bin/network-sh-functions ]; then

В 2.22.0-13-g78001064a я специально реализовал проверку фич о которой мы
говорили.

> > Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network
> > не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть
> > путём эмуляции указания /proc/cmdline.
> 
> /proc/cmdline удобен тем, что можно что-то подлатать на лету,

подхакать на лету.

> Даже ядерщики дожили до bootconfig.

Мне кажется ты совсем не понял, зачем они это сделали.

> Я понимаю, что когда ты писал код фич, ты не
> рассчитывал на их повторный запуск. Но как мне быть, если нужно не
> сконфигурированную фичу сконфигурировать и перезапустить? Не делать же
> очередной форк!

Не нужно форкать. Нужно сформировать конфиги, которые используются кодом.
Если код не готов, то нужно предложить патч, который это поправит.

> Твоя фича рассчитывает на параметры из /proc/cmdline.

Ты не понял мой код. Фича network не рассчитывает на параметры из
/proc/cmdline. У неё есть генератор, который преобразует общепринятые
параметры [1] в формат своих конфигов. Она вообще может обойтись без этого
генератора, если конфигурпцию положить в образ при генерации.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/nfs/nfsroot.rst#n88

> А полная совместимость с пропагатором требует другого синтаксиса

А зачем эта совместимость ? Ты пишешь про это как про аксиому.

Я не хочу отвлекаться на кулстори, но когда мы с inger@ писали инсталлер,
то как-то пережили отсутствие совместимости с mandrake. А тут внезапно
появилось желание иметь совместимость с его частью.

> > [...]
> > Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны
> > на системном уровне, чтобы весь код был готов к изменению параметров, но
> > почему-то меня не услышали.
> 
> Тебе видней, как это реализовать на системном уровне, разве кто-то будет
> возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал
> перетащить на верхний уровень bootchain-interactive

Я не понял как ты предлагал это перетакивать. Скопировать код в другой
репозиторий ?

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

Я уже выше писал, что начал тоже так думать. Пусть всё это пока живёт в
make-initrd-bootchain.

> Про перевод всех параметров
> /proc/cmdline в форму диалогов я правда слышу в первый раз. Мне кажется
> сомнительной такая возможность.

Я говорил не про другие параметры /proc/cmdline, а про дополнительную
информацию и интерактивщину. Последняя уже есть в fsck и luks.

> > > > > Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у
> > > > > нас снимется много вопросов о том, как интегрировать bootchain/interactive с
> > > > > уже имеющимися фичами make-initrd. Будет хороший пример, как это можно
> > > > > сделать.
> 
> P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её
> апстримить. Вот прямо сегодня! :-)

Я уже высказался про это выше.

> Самое жёсткое пересечение -- это форк фичи pipeline в bootchain, только оно
> может затронуть нынешних пользователей pipeline, коих не так много.

Это нужно обсуждать.

-- 
Rgrds, legion