From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3E9E7E8A.1060907@altlinux.com> Date: Thu, 17 Apr 2003 14:14:34 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030210 X-Accept-Language: ru-ru, en MIME-Version: 1.0 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> In-Reply-To: X-Enigmail-Version: 0.70.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0C6059A24BFF500EA074576D" 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: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0C6059A24BFF500EA074576D Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Ed V. Bartosh пишет: > Hello, Anton > AF> Удобство эксплуатации - безусловно, важный момент. А о > AF> каком удобстве _эксплуатации_ может идти речь, если > AF> вместо одного пакета появляется десяток-другой ? > Это для сборщиков-комплектаторов ядер этих пакетов десятки, это и > позволяет гибко комплектовать окончательные kernel-image с набором > нужных фич. А для юзера собственно ничего не меняется - он берет > понравившийся kernel-image и ставит себе. Не хочет задумываться - > берет std. Зато потом начинаются бонусы - обновляется какая-нибудь > alsa и это не повод для вытягивания нового ядра, апгрэйдится только > один пакет, модуль перегрузил и все. Алса - это так, игрушки. А когда > это, скажем, сетевые драйверы на продакшен сервере или еще что-нибудь > такого же плана ? Насколько удобно будет сборщикам собирать новые пакеты с драйверами и ядра. Пример - выход ядра 2.4.21-финального. Как я понимаю сейчас процесс сборки ядра будет выглядеть примерно так: 1) Nidd собирает kernel-source и выкладывает 2) Мантейнеры соответствующих патчей начинают портировать свои патчи на новое ядро. До тех пор, пока все не запортируются - нет возможности собрать std-sub ядро 3) После портирования патчей мантейнеры ядер начинают медленно и упорно собирать собственно сами ядра (не забыть, что еще нужно всем владельцам пакетов kernel-feat, входящим в kernel-image запортироваться на новое ядро (если есть необходимость)) Лично мне не очень нравится пункт 2, ибо тогда задержка с портированием хоть одного мантейнера патча или функционала будет держать всех остальных. Есть идеи, как это обойти ? Может быть прописать в policy, что в случае задержек мантейнер ядра имеет право пересобрать пакет с функционалом? > > AF> Пример: у меня есть некая железка, неизвестного > AF> производителя. lspci сказал, что для нее неплохо было бы > AF> использовать драйвер noname.o, которого в стандартном > AF> ядре не оказалось. Вопрос - где искать этот драйвер? > В ядре, используемом для инсталяции и в std должно быть все железо. > В терминах пакетов - все пакеты kernel-feat-drivers-... > Да и в остальных ядрах, кроме узкоспециализированных, заточеных под > конкретное железо, тоже. Тогда таких проблем не будет. > да, конечно. > AF> Тогда нам соответственно нужна будет таблица аля > AF> ldetect-lst, в которой будет прописано, в каких пакетах - > AF> какие модули. > Не обязательно, если включить в ядро все железо. В виде зависимостей > на пакеты с драйверами, а не собирать с ядром. По возможности, конечно. Да. Понял. Но все-таки неплохо было бы иметь такую возможность - ставить только те пакеты с драйверами, которые необходимы. Собственно в инсталяторе есть сейчас такая штука, но она реализована в виде хаков (прямо прописаны какие пакеты устанавливать если есть потребность в определенном драйвере). Но от таблицы я бы не отказался - будет хороший помошник для авторов kernel-image. > > AF> Необходимо будет поправить kudzu и инсталятор от MDK на > AF> предмет использования этой таблицы при определении > AF> устройств и установке пакетов. > > AF> kudzu придется править достаточно сильно. > А если гарантированно все пакеты с железом будут проставлены ? Тогда проблем не возникнет. Вопрос тогда в том, какой виртуальный пакет будет ставить все пакеты с железом и как сделать так, что бы все пакеты с железом пападали в список зависимостей у виртуального пакета. Желательно - автоматически ;-) > Все модули ? И каждый раз при обновлении какого-либо драйвера этот > архив пересобирать ? И ядро пересобирать ? Нет, ядро не пересобирать.Пересобирается модуль и генерится некий файл с описанием какие модули есть, каких ??? версий ???. Т.е. - фактически репозитарий драйверов. > И вытаскивать/устанавливать ? Через сеть можно забирать только модули. P.S. По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто считает это бредом - не комментировать. И так ясно, что этот путь сложен и необычен. Это как бы предложение по улучшению текущей структуры. --------------enig0C6059A24BFF500EA074576D Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+nn6Oqohfd2vlwKsRAhkPAJwI0WLYYDy+diAwYrc4Dsv/XHwchQCdGher j3n0QT7ig0K/bi27OBs32I0= =H+st -----END PGP SIGNATURE----- --------------enig0C6059A24BFF500EA074576D--