From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 23 Sep 2021 02:45:10 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210923004510.vwdythqavekqoow3@example.org> References: <20210922100901.e5dsw554g6elb3lx@example.org> <52f4526d-7fa7-e0ed-6d2d-12e06f20408c@gmail.com> <20210922114132.yaobsgcz7vrkjgbq@example.org> <8d262440-d8fc-c174-3293-1964e3440617@gmail.com> <20210922130839.b4iwv2arqyggczb3@example.org> <20210922144619.3h4va7j4u6m36mka@example.org> <20210922190348.rrn3cjywjwwcrhbl@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] =?utf-8?b?dWRoY3BjIHNjcmlwdCDQsiDRhNC40YfQtSBuZXR3?= =?utf-8?q?ork?= 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: Thu, 23 Sep 2021 00:45:12 -0000 Archived-At: List-Archive: 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