Re: [d-kernel] kernel policy

[Anton Farygin <rider@altlinux.com>]

[-- Attachment #1: Type: text/plain, Size: 4022 bytes --]

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.
По поводу репозитария драйверов - это мысли вслух. Просьба тем, кто 
считает это бредом - не комментировать. И так ясно, что  этот путь 
сложен и необычен. Это как бы предложение по улучшению текущей структуры.

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]