From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=oGey55KfM6AgFkGOspY0RRWa5ugpI7BW35d5kYlfEa4=; b=IWKqE13yjdQtr4op9Mes/Sr600SYOkENqLKv/L7WnRT0b8ufdCEmrtOl2T/NX4jcfu mxUFTItJKBwVcPTxdq7XFXYbz6TusmfjAWdznlSlJDYBIwXbfm23adT8Iw4hFNsFQUw0 QmJiW3QOCtBa/0XCHvcJRsBQlKAOv51M83aFyj3Zcb9mtPpti+T7JbMQ/bqyV/A3jqL4 yXcfhMRX8XIHKiB+nvpnOHUG/VZ9KVtn77b3HDRmqVniUHH+zjH3IQjdyIaIkSt+/kmA wFwMlafFbXljNAfVtfQYmjazJkUtUOX1cfsZ/TyuIikE+Hjtk8pMChi20Hap04XoylB6 lRug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=oGey55KfM6AgFkGOspY0RRWa5ugpI7BW35d5kYlfEa4=; b=mkwQ1vxzqHQCt7o6oSud84LbtpTTb2jPTb/zEWdCLPQ6D7HF7FFwLGZB7k/rUnVxUU UH6EayIrYaJ3JKxNd4JHt/W7gaU2wUWv000kCzAsBaJPFtZ/uqLD9Q+rVxgzmmbFHOUO 81jGPb6yhPlbsor/qlpmJwiZdO5UidfFg76uHYFdFIEiJbHDS79rfYt++vjhsRRl8hFr uTaKxHAjBmLA3Gj2cabAGlHofTa5GZmB/Esi58Cp7KXt7Br7l4vkSqTiORbOa5buXvZW 1kdySutma4piuMVeM5TFKU/daBVYp4XrXuX0oK1TF6c99xaS2Z/NDIPzJbhVUGa6o1VY ae/w== X-Gm-Message-State: AOAM5320BQV2A7KWgHh5So6SApxFTrXTuEa5FGTW4pAgJBIF8LkUEvwp DBMiVyjhOvvu/aBEqORCVG5e1RRBoJU= X-Google-Smtp-Source: ABdhPJxIDr7CVRnR5qcuTKpdtr/8uQGlKjyVsCeARk/1M7tpodXMJY0yTfG9gSYqsbnu/g7gWWvqIg== X-Received: by 2002:a05:6512:4017:: with SMTP id br23mr1133207lfb.467.1632348394260; Wed, 22 Sep 2021 15:06:34 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20210917220845.s4dgl2hqla7yt4pe@example.org> <5815442b-e5a1-7469-b705-24090749e245@gmail.com> <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> From: Leonid Krivoshein Message-ID: Date: Thu, 23 Sep 2021 01:06:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210922190348.rrn3cjywjwwcrhbl@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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: Wed, 22 Sep 2021 22:06:38 -0000 Archived-At: List-Archive: 22.09.2021 22:03, Alexey Gladkov пишет: > On Wed, Sep 22, 2021 at 07:12:06PM +0300, Leonid Krivoshein wrote: >> [...] Поэтому >> я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах >> после запуска udev то, что не было сконфигурировано в командой строке, на >> худой конец, прибегать к технике повторного сканирования, реализованной в >> пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev. > А то что хочешь делать ты не ложится в текущую архитектуру. Во многих > местах код рассчитывает, что конфигурация уже задана. Настройка сети одно > из таких мест. Эвенты от интерфейса будут проигнорированы если нет > конфигурации. В сегодняшней версии 0.1.5-alt3 эту проблему устранили, благодаря тебе, конечно лучше глянуть код. Уже проверил и скоро выгружу. Теперь сеть идеально взлетает без диалогов и без форка фичи network. Без диалогов -- временная мера, просто сделан задел на будущее. Если сравнивать altboot с propagator, то один из минусов первого -- отсутствие диалогов конфигурирования сети. Но благодаря фиче network в самом make-initrd это можно пережить, хотя лучше, чтобы эти диалоги тоже были. Другой минус, я надеюсь, мы тоже почти преодолели -- он в теме. Теперь все те же опции мы можем брать по протоколу DHCP. А других минусов нет, остаются только плюсы, их становится всё больше. > То есть придётся понимать такую ситуацию и ставить очередь network на > паузу в ueventd. Это решит одну проблему, но все. Как раз я представлял себе работу всего pipeline/bootchain с диалогами, в целом, как полноценную программу, работающую в обычной среде. Мы же не останавливаем в stage2 работающий udev каждый раз, когда нам что-то нужно. Propagator работает параллельно с udev, такое же поведение у altboot. Главное, как мне кажется, это две вещи: make-initrd при root=pipeline/bootchain ни при каких обстоятельствах не должен найти корень раньше, чем ему об этом скажет pipeline/bootchain, какие бы эвенты ему не пришлось параллельно обрабатывать. И второе: код самих pipeline/bootchain/altboot должен быть готовым работать в ситуации готовности к начальной загрузке, чтобы сканировать, ждать, если устройств ещё нет, при этом не создавать рейсов. Тогда эта концепция будет работать. Про диалоги и опции конфигурирования отдельно скажу. > Если ты хочешь вернуться в начало, то нужно будет уметь откатываться на > исходное состояние и начинать с начала. К этому некоторый код вообще не > готов. К этому всегда должен быть готов код в altboot. Сейчас он пишется с таким расчётом. Сеть там просто единожды опрашивается, поднятый интерфейс запоминается. При перезапуске altboot используется ранее созданная конфигурация. Пока так... > Начало происходить то чего я опасался. Не начало и не начнёт. Напротив, ждём не дождёмся, когда это закончится! Вот и Антон Мидюков вчера настаивал, чтобы я приступил к процессу апстрима, т.к. почти все его замечания были устранены, а он проверяет на всех мыслимых кейсах и регулярках, на разных архитектурах. Не начнёт, потому что мне эту ношу не потянуть, я лишь помогу в той части, что обещал, но не более. > Ты где-то отдельно пишешь код Код отправляю пока в Сизиф и в локальную гитовницу: git.altlinux.org/people/klark/packages/make-initrd-bootchain.git > вместо того чтобы обсуждать и порциями добавлять. Если бы работы по обсуждённому ранее плану были завершены, мне бы только и оставалось, что добавлять порциями. Но к сожалению работы ещё много. Ты сам настаивал, чтобы продукт был тщательно проверен до того, как он поедет в апстрим. Находятся замечания, предложения, приходится их устранять и учитывать. А из-за этого у меня откладывается работа по автоматизации тестового стенда. Конечно лучше, чтобы в апстрим поехал безупречно работающий продукт. Ты и сам уже можешь посмотреть код в Сизифе, пощупать очередные регулярки с разными опциями и методами загрузки. Лично мне кажется, что ни один пакет у нас так пристально не проверялся, попадая в обычные продукты. Но altboot -- важное звено в процессе загрузки и моя задача учесть совместимость с уже сделанным в Альте за многие годы. > В итоге ты уверенно > движешься к форку уже самого make-initrd (именно это ты и делаешь, > поверь). Поверь, этому не бывать! ;-) > Ты уже спроектировал и реализовал свою систему так с чем я не > могу согласиться. Предлагаю не делать поспешных выводов. Фичи pipeline и network ты спроектировал. propagtor проектировал не я, но мне приходится во многом повторять его и его поведение, при этом я стараюсь не делать форк фич там, где это возможно, мы решаем задачу по избавлению от propagator и запихиванию его функционала в make-initrd. Всё это проделано зря, если вместо propagator предложить в чистом виде pipeline или иную новую концепцию загрузки, которая будет идеальной с точки зрения make-initrd, но непригодной для реального применения без переделки всего остального. Как раз я старался учесть возможность перехода в будущем на более правильные концепции. Но сейчас и тебе надо принять, как данность, что пусть "функционал пропагатора" с твоей точки зрения не идеален, лучше чтобы он был внутри make-initrd и работал как 1/80 часть его рантайма, а не наоборот, чтобы настоящий propagator полностью выкидывал и заменял собой все 100% рантайма make-initrd. Можно и нужно обсуждать, как лучше сделать это, не ломая совместимости, и учитывая потребности перехода на что-то более правильное в перспективе. > И я до сих пор не видел ни одного патча. Поэтому для > меня каждая твоя проблема является большим сюрпризом. Кажется, несколько попыток я уже делал, в частности, отдельно предлагал bootchain-interactive. Но, как я понял, ты хочешь принять всё одним разом, и только после тщательной проверки всей связки. Так мы этой проверкой сейчас занимаемся. После этого мне ещё README для каждой фичи писать и только потом делать коммиты в апстрим -- таков был план. > [...] > Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у > тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp > нужно аккуратно остановить. В текущей простой ситуации, которую нельзя назвать финальным/идеальным вариантом, у пользователя нет шансов что-либо захотеть. :-) 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 Т.е. в версии 0.1.5-alt2 тут вообще диалог о том, что "перезагрузись и сконфигурируй сеть через /proc/cmdline". В версии 0.1.5-alt3 этот же диалог и перезагрузка будет только в случае, если недоступен протокол IPv4. > [...] > Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network > не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть > путём эмуляции указания /proc/cmdline. /proc/cmdline удобен тем, что можно что-то подлатать на лету, обойти проблемы, но это не лучшее место для хранения конфигурации. Даже ядерщики дожили до bootconfig. Я понимаю, что когда ты писал код фич, ты не рассчитывал на их повторный запуск. Но как мне быть, если нужно не сконфигурированную фичу сконфигурировать и перезапустить? Не делать же очередной форк! Твоя фича рассчитывает на параметры из /proc/cmdline. А полная совместимость с пропагатором требует другого синтаксиса, который я мог бы расширить. В общем, я прикладываю усилия, чтобы использовать твою готовую фичу. И кажется, это удалось! Я же как раз не хочу делать форк всей или даже части фичи network, хотя и она "часть замены пропагатора", напротив, есть желание пристроится к уже готовому. > [...] > Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны > на системном уровне, чтобы весь код был готов к изменению параметров, но > почему-то меня не услышали. Тебе видней, как это реализовать на системном уровне, разве кто-то будет возражать! Я не так хорошо пока знаю архитектуру make-initrd, но предлагал перетащить на верхний уровень bootchain-interactive. Кстати, только сегодня думал, что может как раз не стоит перетаскивать, а лучше оставить в составе пошаговой загрузки на отдельном терминале. Потому что разные фичи (запущенные демоны) должны выстраиваться в очередь, диалоги не должны мешаться, они не всегда бывают диалогами ввода. Про перевод всех параметров /proc/cmdline в форму диалогов я правда слышу в первый раз. Мне кажется сомнительной такая возможность. Но пристраивание диалогов к имеющимся фичам мы тоже хотели с тобой обсудить и возможно нам сегодня удалось это реализовать, ниже-то речь как раз об этом: >>>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >>>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >>>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >>>> сделать. P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её апстримить. Вот прямо сегодня! :-) А там уже будем обсуждать изменения, необходимые сразу и после апстрима. Я уверен, что хуже от этого никому не станет. Даже если что-то там ещё окажется не идеальным, наличие altboot внутри make-initrd не помешает никому собирать образы с проверенным пропагатором. И никто не заставляет ставить фичи типа make-initrd-bootchain в свою систему. К тому же эта версия последняя, исправляющая замечания, две следующие планировались по "хотелкам", которые можно отложить на полгода. Самое жёсткое пересечение -- это форк фичи pipeline в bootchain, только оно может затронуть нынешних пользователей pipeline, коих не так много. -- Best regards, Leonid Krivoshein.