From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Mailer: Gnus v5.8.8/XEmacs 21.4 - "Portable Code" X-Comment-To: Anton Farygin To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel policy References: <20030415144045.GA13440@shamrock.office.altlinux.ru> <87he8zljh6.fsf@velvet.po.cs.msu.su> <3E9C5571.2040009@altlinux.ru> <3E9D746E.5040006@altlinux.ru> <3E9E4517.3070500@altlinux.com> <3E9E6A76.6050402@altlinux.com> <3E9E7E8A.1060907@altlinux.com> In-Reply-To: <3E9E7E8A.1060907@altlinux.com> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: 17 Apr 2003 14:34:00 +0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: devel-kernel-admin@altlinux.ru Errors-To: devel-kernel-admin@altlinux.ru X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel-kernel@altlinux.ru List-Unsubscribe: , List-Id: ALT Linux kernel packages development List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Hello, Anton >> Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и >> позволяет гибко комплектовать окончательные kernel-image с набором >> нужных фич. А для юзера собственно ничего не меняется - он берет >> понравившийся kernel-image и ставит себе. Не хочет задумываться - >> берет std. Зато потом начинаются бонусы - обновляется какая-нибудь >> alsa и это не повод для вытягивания нового ядра, апгрэйдится только >> один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда >> это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь >> такого же плана ? AF> Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра. Не знаю. Нужно попробовать. Но, вообще, для тех драйверов, которые выкладываются производителями железа как раз такой подход и является более прямым, их приходится точить для сборки в составе ядра. AF> Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс AF> сборки ядра будет выглядеть примерно так: AF> 1) Nidd собирает kernel-source и выкладывает AF> 2) Мантейнеры соответствующих патчей начинают портировать свои патчи AF> на новое ядро. До тех пор, пока все не запортируются - нет возможности AF> собрать std-sub ядро Предлагаю назвать его kernel-image-common-тра-та-та и отразить этот факт в полиси. В случае, если такая стратегия таки будет принята. При переходе на новую версию сборка базы - это первоочередная задача и все все бросают и точат свои патчи под новые сорцы. Если кто-то не может, не успевает, то его патч подделают другие, не вижу тут проблем. AF> Тогда нам соответственно нужна будет таблица аля AF> ldetect-lst, в которой будет прописано, в каких пакетах - AF> какие модули. >> Не обязательно, если включить в ядро все железо. В виде зависимостей >> на пакеты с драйверами, а не собирать с ядром. По возможности, конечно. AF> Да. Понял. Но все-таки неплохо было бы иметь такую возможность - AF> ставить только те пакеты с драйверами, которые необходимы. Собственно AF> в инсталяторе есть сейчас такая штука, но она реализована в виде хаков AF> (прямо прописаны какие пакеты устанавливать если есть потребность в AF> определенном драйвере). Но от таблицы я бы не отказался - будет AF> хороший помошник для авторов kernel-image. Возможно это и так. Но у меня пока нет идей как это грамотно сделать. >> А если гарантированно все пакеты с железом будут проставлены ? AF> Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный AF> пакет будет ставить все пакеты с железом и как сделать так, что бы все AF> пакеты с железом пападали в список зависимостей у виртуального AF> пакета. Желательно - автоматически ;-) Можно. По названиям пакетов. Полуавтоматически :) >> Все модули ? И каждый раз при обновлении какого-либо драйвера этот >> архив пересобирать ? И ядро пересобирать ? AF> Нет, ядро не пересобирать.Пересобирается модуль и генерится некий файл AF> с описанием какие модули есть, каких ??? версий ???. Т.е. - фактически AF> репозитарий драйверов. >> И вытаскивать/устанавливать ? AF> Через сеть можно забирать только модули. Тогда я не вижу принципиальных отличий от модулей в пакетах, кроме размера. Но тут могут возникнуть другие проблемы, например с взаимозависимостью модулей. AF> По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто AF> считает это бредом - не комментировать. И так ясно, что этот путь AF> сложен и необычен. Это как бы предложение по улучшению текущей AF> структуры. Если не дробить столь мелко, то такой репозиторий - это все пакеты kernel-module-drivers-... Чем плохо ? -- Best regards, Ed V. Bartosh