Автообновление драйверов - панацея для Linux

блин поправьте "распространение и драйверка" на "распространение драйвера"

Без стабильного driver API это не имеет смысла. А так как стабильный API не имеет смысла, то вся затея бессмысленна в квадрате :)

Поверь мне, не в стабильном api счастье!

Я так понял, будет какой-то свой API для создания драйвера, стабильный, и будет драйвер, который будет обеспечивать прослойку между текущим API ядра и своим особым. Таак, например сделан драйвер nvidia.

а потом ещё прослойка и ещё.

да я не спорю, самый быстрый USB-стек в мире, это не шутки :)

>а потом ещё прослойка и ещё.

ничего страшного, просто появится какой-нибудь gtk3++, который будет прослойкой всех прослоек в прослойке :)

неа, наврал, это просто система для автоматической сборки драйвера под нужную версию ядра.

Сейчас придут гентушнеги и начнут ржать над костылями. :)

Dell Linux - проект фирмы Dell? Тогда респект им, а я думал они только на ноуты линукс ставят...

Хотел написать об этом ещё вчера, но инициатива кажется мне бредовой в свете того, что у ядра API нестабильно, а значит драйвер из новой версии ядра просто не заведётся в старом.

Короче, дело темное - как оно работает - не ясно.

Я с месяц назад размышлял, что было бы здорово написать такую утилиту, которая будет по конфигу собирать модуль под нужное ядро.

причем и вручную и прямо при загрузке ядра, если драйвер под него еще не собран.

Короче, идею продумал, даже название придумал, а потом посмотрел, а оказывается это в чистом виде dkms и он уже написан. А потом yum search dkms сделал и выяснил, что он уже в федоре есть, причем последней версии... ;)

Робяты вновь изобрели module-assistant? Это есть гуд. Больше велосипедов хороших и разных.

>Сейчас придут гентушнеги и начнут ржать над костылями. :)

Над своими?

У гентушников есть module-rebuild и они не парятся

Мда, только в чём панацея для пользователей я так и не понял:) Для дистроклепателей просто меньше головной боли с пересборкой всех модулей. А я то уже надеялся, что сделали какой-то API/ABI для внешних доайверов:(

аж голова закружилась

Пакеты с драйверами nvidia из freshrpms используют dkms. Все просто: при загрузки системы определяется, есть ли нужный модуль для работающей версии ядра. Если нет - компилируется.

ИМХО Имеет смысл для драйверов устройств, не критичных к скорости.

> стабильный API не имеет смысла

Для разработчиков ядра -- да. А вот для многих других -- жуткий геморрой: 1) вендорам приходится постоянно что-нибудь фиксить в своих драйверах с каждой новой версией ядра; 2) юзерам приходится ждать, когда вендор выпустит обновление. В итоге недовольны и те, и другие.

Fedora 7:

$ rpm -qi dkms
Name : dkms Relocations: (not relocatable)
Version : 2.0.16 Vendor: Fedora Project
Release : 1.fc7 Build Date: Срд 28 Фев 2007 18:56:42
Install Date: Вск 22 Июл 2007 00:48:38 Build Host: ppc2.fedora.redhat.com
Group : System Environment/Base Source RPM: dkms-2.0.16-1.fc7.src.rpm
Size : 168521 License: GPL
Signature : DSA/SHA1, Птн 18 Май 2007 21:41:45, Key ID b44269d04f2a6fd2
Packager : Fedora Project <http://bugzilla.redhat.com/bugzilla>;
URL : http://linux.dell.com/dkms
Summary : Dynamic Kernel Module Support Framework
Description :
This package contains the framework for the Dynamic
Kernel Module Support (DKMS) method for installing
module RPMS as originally developed by Dell.

Идея может быть и хорошая, если бы не куча глюков. Руками оно всё таки надёжнее.

> Ну, далеко не все "гентушнеги" употребляют наркотики перед тем как зайти на ЛОР!

Своей дури хватает?

>anon> Сейчас придут гентушнеги и начнут ржать над костылями. :)

Ну, далеко не все "гентушнеги" употребляют наркотики перед тем как зайти на ЛОР!

Не знаю, что они задумали, но в Линуксе нет (и надеюсь не будет) стабильного API для драйверов. Более того, модуль зависит не только от версии ядра, но и от опций компиляции. Можно, конечно, создать прослойку, потом еще одну, но это будет потеря производительности, и, возможно, гибкости. ИМХО, чем больше бинарных дров выпустят, тем больший глюкодром получат.

Фраза "In turn, this enables Linux distributors and driver developers to create driver drops without having to wait for new kernel releases." звучит смешно. Ничего не мешает в рамках дистрибутива выпускать разные сборки одного ядра и обновлять для них модули, и совсем не нужно ждать новый релиз ядра. RedHat прекрасно выпускает работающие, хотя и сильно пропатченные ядра.

А фразу: "This lets us fix and replace individual device drivers to support new hardware without having to respin the whole CD like we wound up doing for Ubuntu," said Domsch." я совсем не понял. В Ubuntu нельзя поменять ядро???

Мдя, дядя, а ты предлогаешь весе дрова для всевозможного железа вот так прям в ядро запихнуть ? Вот тут крик идет что разработчики ядра уже не могут в этом зоопарке нормально разбираться. Если сейчас об этом не задуматься, потом может быть поздно, будет это паделье глючить хуже висты...

Пяти _лет_???

вот кто собирает машину времени для лора

Чуваки! Панацей не существует! Поправьте на "решение" или что-нибудь в духе.

Кстати у меня эта DKMS уже хренову гору времени стоит и регулярно собирает mppe модуль для ядра.

И получится еще один FreeBSD. Кто знает, тот поймет.

П.С. именно из за такого API я - фанат FreeBSD от него отказался в пользу Linux.

> Мдя, дядя, а ты предлогаешь весе дрова для всевозможного железа вот так прям в ядро запихнуть ? Вот тут крик идет что разработчики ядра уже не могут в этом зоопарке нормально разбираться. Если сейчас об этом не задуматься, потом может быть поздно, будет это паделье глючить хуже висты...

Бедный, тяжело тебе, наверное...

ГЫ! Сначала подумал, что это разработка Deli Linux (http://delili.lens.hl-users.com) - есть такой дистро на основе Слаки для древних компов :-)

Ето тот же module-assistant но не только для Debiana а для любого Linux.

А по моему - не стоит возводить нестабильность API в абсолют. Да есть нестабильные части. Но наверняка есть и стабильные. Или редко изменяемые. Вот для таких DKMS - полезная штука. Даже если что-то и поменяется, то можно для оперативности обеспечить обратную совместимость на уровне DKMS. Оставив рабочими все зависимые модули. А затем потихоньку дорабатывать модули. Разработчиков ядра и драйверов это может сильно разгрузить. А конечным пользователям не пийдётся ждать слишком долго. Вот например я не силён в линуксовой компиляции. Времени разбираться с этим нету. А нормальную поддержку Intel HD Audio реализовали только в последней версии ALSA. Когда она попадёт в ядро - непонятно. А так я бы уже имел эти драйвера и не парился с записью с TV тюнера >-).

> Поверь мне, не в стабильном api счастье!

Докажи! Я хочу чтобы один и тот же драйвер работал без перекомпиляции на ядрах 2.6.0-2.6.23. Объясни почему я должен при обновлеии ядра пересобирать все сторонние драйвера?

> Не знаю, что они задумали, но в Линуксе нет (и надеюсь не будет) стабильного API для драйверов. Более того, модуль зависит не только от версии ядра, но и от опций компиляции. Можно, конечно, создать прослойку, потом еще одну, но это будет потеря производительности, и, возможно, гибкости. ИМХО, чем больше бинарных дров выпустят, тем больший глюкодром получат.

И чо ты надеешься? Ты мазохист?

> Объясни почему я должен при обновлеии ядра пересобирать все сторонние драйвера?

Не хочешь собирать драйвера - используй FC/Ubuntu/другой user-friendly дистрибутив, чего плакаться то?

> ИМХО Имеет смысл для драйверов устройств, не критичных к скорости.

Глупости. Драйвер, собранный через DKMS никак не отличается от собранного вручную.

Да, пять лет изобретать m-a - это вам не шутка.

> Я хочу чтобы один и тот же драйвер работал без перекомпиляции на ядрах 2.6.0-2.6.23.

Зачем?

Не хочешь собирать драйвера - используй FC/Ubuntu/другой user-friendly дистрибутив, чего плакаться то?

А то, что бывают еще и закрытые дрова :(

> Сейчас придут гентушнеги и начнут ржать над костылями. :)

ГЫ ГЫ ГЫ

>> стабильный API не имеет смысла
> Для разработчиков ядра -- да. А вот для многих других -- жуткий
> геморрой: 1) вендорам приходится постоянно что-нибудь фиксить в
> своих драйверах с каждой новой версией ядра
Так сейчас-то все драйвера и так в ядре (проприетарные
для двух видюх - не в счёт), и по этому вендорам ничего
фиксить не приходится.
А так - не понятно. Как я понял из статьи, DKMS - это не
прослойка, а просто фрэймворк для _сборки_ дров вне ядра.
Что-то типа того, что в ALSA сделали - там тоже дрова
можно вне ядра собирать.
И вот тут-то и получится, что с каждым релизом ядра, если
какой-то API изменили, вендорам сразу придётся фиксить
дрова, при чём на старых ядрах они либо перестанут
собираться, либо надо будет делать #ifdef'ы всякие.
В общем, надо читать доки по этому DKMS, а мне лень. :)

> 2 Rozik (*) (24.09.2007 22:40:08)

> Покайтесь, братие - линуксокапец близок :)

Нет! Не дождёшься! :-)

2 anonymous (*) (24.09.2007 22:46:32)

> Объясни почему я должен при обновлеии ядра пересобирать все сторонние драйвера?

А что, лень раньше Вас родилась? Хоть где-то... как-то... Но, есть RH, однако. ;-))

>> Я хочу чтобы один и тот же драйвер работал без перекомпиляции на ядрах 2.6.0-2.6.23.

>Зачем?

Затем, что бывает еще специфичное железо, с бинарным драйвером под определенное ядро.

Вообще, а что такое "драйвер"??? Ну, модуль (ядра или к ядру) я как-то понимаю... :-)

УРА!!! ВЕНДЕ КАПЕЦ ЕЩЕ БЛИЖЕ!!! БАНЗАЙ!!!

>И чо ты надеешься? Ты мазохист?

Не понял ваш пост, но на всякий случай отвечу.

Нет не мазохист. Да надеюсь (правда непонятно на что).

хм, у меня уже 100 лет стоит, dkms входит в состав Mandriva 2007