From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 23 Sep 2021 13:38:14 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20210923113814.ib7rjlvungq6gcyn@example.org> References: <20210922114132.yaobsgcz7vrkjgbq@example.org> <8d262440-d8fc-c174-3293-1964e3440617@gmail.com> <20210922130839.b4iwv2arqyggczb3@example.org> <20210922144619.3h4va7j4u6m36mka@example.org> <20210922190348.rrn3cjywjwwcrhbl@example.org> <20210923004510.vwdythqavekqoow3@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 11:38:17 -0000 Archived-At: List-Archive: On Thu, Sep 23, 2021 at 05:40:10AM +0300, Leonid Krivoshein wrote: > > Этот репозитории повторяет стратегию make-initrd-propagator, который > > как-то встраивался в make-initrd. И то и другое отдельно стоящие вещи в > > себе. Новый, правда, интегрирован с основным кодом лучше. > > Я так понимаю, это всё из-за интеграции с network. Но посуди сам: pipeline и > network, плюс ещё несколько новых фич, это и есть тот набор, что ты сделал > на замену пропагатора, я лишь приделываю к этому диалоги и совместимость с > нынешним stage2. Если что-то не так приделываю, можно же это предметно > обсуждать. Да, я сначала думал делать полный или частичный форк фичи > network, потому что были большие сомнения, что удастся с ней > интегрироваться. Но это последнее, что нужно было altboot, чтобы быть больше > похожим на propagator (по возможностям) и удалось обойтись без форка, в > отличии от pipeline. Ты можешь сказать, чем плоха такая интеграция? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918 > -- работает просто идеально. К вопросу о ревью: вот и как предполагается комментировать код с git.alt ? Ок, буду по ссылкам. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l12 Про это я уже писал. Это проверяется не так. Остальной интегрируется так, что не использует ничего из того с чем интегрируется. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l32 В network-sh-functions есть ipv4_enabled. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l51 Теряются абсолютно все ошибки. Ошибки в ip=, в macaddr, в указании масок. Вместо всего этого будет "can't reconfigure network settings". Этого быть не должно. Также я уже говорил, что я думаю про дёргание /lib/initrd/cmdline.d/network. http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l56 Этот шаг можно выполнить лишь один раз. Это не вяжется у меня с "Can't bridge up network interface. Try with other network settings, wired connection and/or cable." Если пользователь попробует тот же интерфейс с другими настройками, то второй раз проверки не будет ??? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l65 Хардкод имени интерфейса. is_loopback(). http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l67 Для чего эта проверка ? http://git.altlinux.org/tasks/index/sisyphus/tested/285722/gears/100/git?p=git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=9f555ab3a44c83e2c54c949f2d9401d6f6995ed2;hb=0b2522e81ea6279295bae02a8aa77e84c86d3918#l73 Я полагаю это проверка на то что интерфейс поднят ? Если да, то is_link_up Если проверка на присутствие адреса, то "/.initrd/online/$NET_IF". > > Кроме того, если тебе нужно поведение propagator, то он уже есть и незачем > > его переизобретать. > > Выше озвучивались не просто общие слова -- у нас куча граблей и нет способа > быстро перейти на make-initrd + pipeline с ними. Вот простейший пример, мы > готовимся избавиться от isolinux для legacy/x86, но сколько это будет > тянуться -- неизвестно. Он сам (его брэндинг) добавляет опции пропагатора в > загрузку и на это приходится ориентироваться, так как если не работает, > сразу баг. Я уж не знаю вашей кухни, но вообще-то, да, это сразу бага. Бага на брэндинг. Он передаёт устаревшие параметры. Новый make-initrd+bootchain всё равно требует либо дополнительных, либо других параметров для включения новых фич. > > Считаю ли я, что поведение propagator нужно воспроизводить ? Нет. > > В каком смысле? Я не копировал его повеление в точности. Но методы -- нужны, > совместимость со stage2 -- нужна. Многое сделано лучше и модульно, это > нельзя назвать 100% копией поведения. И всё делалось в пределах исходной > концепции pipeline, код декомпозирован. Если ты не копируешь повеление в точности, то пожалуйста поясни свой тезис: > Но сейчас и тебе надо принять, как данность, что пусть > "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был > внутри make-initrd Если ты не занимаешься копированием, то неправильного "функционала пропагатора" в новом коде быть не должно. > > Я считаю, что должна быть сохранена совместимость до определённой степени. > > Я не считаю, что нужна полная копия поведения. Для последнего у вас есть > > сам propagator. > > Его уже начали капитально переделывать под новые реалии. Но без меня. http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=08639c8fafa30e0f78d19f1c5831fd2b1cc2bc02 Это, кстати, интересно. > > > Можно и нужно обсуждать, как лучше сделать это, не > > > ломая совместимости, и учитывая потребности перехода на что-то более > > > правильное в перспективе. > > Ты сам себе противоречишь. Я должен принять, как данность функционал > > пропагатора и не ломая совместимости с кодом 17 летней (на самом деле > > большей) давности переходить на что-то более правильное. > > Коду инсталлятора уже 17 лет? Ваш _инсталлятор_ был написан для Server 4 (который был ещё до branch4). Этот инсталлер, как и предыдущий использовал propagator как stage1. Так что вашему инсталлеру уже примерно 11-12 лет, а propagator же был за долго до него. > > И при этом ты пишешь, что не потянешь сопровождение. Другими словами жить > > с и переписывать эту "данность" с учётом совместимости буду я ? Отличная > > перспектива. > > Вот тут я не понял, что ты предлагаешь. Изначально весь код делался как > часть make-initrd, это же твой проект. Не все модули, которые пишутся для make-initrd автоматически становятся моими. Некоторые так и не попадают в репозиторий. Всё что я принимаю в репозиторий я понимаю и поддерживаю. Я должен понимать код и как он работает именно потому что он переходит от коммитера в репозиторий. > Не, ну давай будем поддерживать всем миром. )) Именно потому что ты ставишь здесь смайлики я и не принимаю просто "написанный код". > Мне кажется, что моя помощь в написании кода, документации, методики > тестирования и инструментов для автоматизации тестирования с лихвой > покроет даже моё неучастие в дальнейшей судьбе. Обычно так и происходит. Коммитер пишет код, тестирует, документирует его, отдаёт в апстрим и идёт своей дорогой. Но так происходит лишь тогда, когда апстрим понимает и согласен со всеми предложенными изменениями. То что ты написал не подпадает под последнее. У меня есть много вопросов как архитектуре фич, так и к реализации. Когда ты решишь разрешишь все эти вопросы, тогда я заберу код, а ты, если хочешь, можешь не участвовать в его дальнейшей судьбе. > Но я могу помогать с поддержкой, по возможности, хотя слабо представляю, > как это возможно, когда это войдёт в состав make-initrd. После вхождения изменений в мой репозиторий я не требую от тебя какой-то поддержки. Но такое возможно лишь при разрешении всех моих вопросов. > > Потому что сейчас всё что, сказал выглядит не очень здорово. Выглядит так, > > что пропагатор переписанный разом на форк pipeline мне пытаются скинуть на > > поддержку. > > Да, есть немного и такого дела. А как бы ты хотел? Я тебя прекрасно понимаю. > Вчера собрались регулярки и не грузится RPi4, сразу ко мне вопрос. В > результате altboot оказался не причём, но так мне хотя бы спокойнее будет, а > тебе какая разница, 80 тыс. строк кода поддерживать или 86 тыс., ты же к > такому уже привык!? :-) Так вот оно что. То есть ты просто единовременно переписал propagator на шелле, а не на make-initrd, потому что твой код использует остальной мой код по минимуму, получил make-initrd-propagator, но теперь с банановым вкусом и хочешь, чтобы уже с новым неподдерживаемым кодом возился я (ты сам пишешь, что не тянешь его поддержку). Нет, Леонид, так просто у тебя скинуть на меня это не получится. Я заберу у тебя только то с чем буду полностью согласен. > > Патчей или PR так и не было. > > Я собирал тестовые задания с патчами, приводил тут на них ссылки. Нет у меня > на гитхабе аккаунта или я не очень понимаю в этой терминологии. Леонид, я не сотрудник, который работает с тобой. У меня нет возможности анализировать тестовые задания и патчи в них. Патчи можно слать по почте в рассылку или лично, можно завести аккаунт на github и делать PR там, как это делает Пётр Михалицын. Ещё раз для ясности: Я не готов лазать по каким-то там тестовым заданиям, пакетам в сизифе с целью "а что бы такого ещё запстримить". Мне это не нужно. > > > > А полная совместимость с пропагатором требует другого синтаксиса > > А зачем эта совместимость ? Ты пишешь про это как про аксиому. > > Потому что есть целая куча пакетов и документации в продуктах к ним, которые > его используют. Например, для работы со слоями NFS, для сетевой установки. Я > уже говорил выше, что речь о совместимости именно с этими многолетними > наработками, которые разом не выкинуть, не заменить. Их не нужно выкидывать. Они могут быть реализованы иначе. Я не говорю, что нужно назло переименовывать всё. Я говорю, что старый подход плохо реализуется в новом коде, то его нужно менять и менять документацию. > > Я не понял как ты предлагал это перетакивать. Скопировать код в другой > > репозиторий ? > > п.7 здесь (самый конец): > https://lists.altlinux.org/pipermail/make-initrd/2021-August/000521.html Ок. Давай процитирую: > > 6. Будешь ли ты сам ревьювить полностью отлаженный код до начала > > процесса > > апстрима или тебе лучше делать это по ходу? > > Мне удобнее по ходу так как если вдруг возникнут вопросы, то править будет > удобнее. Мне удобнее по ходу. По ходу!!! Ты хоть куда-нибудь патчи посылал для обсуждения ? В рассылке их нет. В личке тоже. > > 7. Предлагаю такую последовательность отправки коммитов: > > bootchain-interactive, затем bootchain-core + bootchain-getimage + > > bootchain-waitdev, затем замена фичи pipeline виртуальной зависимостью > > на > > фичи bootchain-getimage и bootchain-waitdev, всё остальное (вся пачка > > altboot), можно одним коммитом. Так пойдёт? > > Вполне. А тут ты про некую последовательность коммитов говорил, но где они ??? Я до сих пор не получил ни одного коммита. Все эти разговоры пустая болтовня какая-то. > и первый ответ тут: > https://lists.altlinux.org/pipermail/make-initrd/2021-August/000525.html > > я был уверен, что уже удалил то задание, но нет. :-) > так это и был патч для make-initrd с фичей interactive. Блин, опять какое-то тестовое задание, где нужно искать, что ты там наменял. Я даже ссылку на строчку в diff с которой не согласен не могу прислать сюда. Ещё бы через DHL распечатки кода прислали. Знаешь, что мне такие "коммиты" даром не нужны. Далее обсуждать такой подход добавления изменений в make-initrd не имеет смысла. Если захочешь узнать как это делается без издевательства на ревьювером, то спроси у Глеба или Димы. -- Rgrds, legion