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

"После пяти лет разработки проект Dell Linux представляет DKMS.." - переводчика на мыло.

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

Не знаю у кого как, но у меня после загрузки нового ядра зачем-то сносит модуль из старого.

это наверное самое большое бедствие для всех пользователей пенгвинов, после каждого обновления, пересобирать все модуля ядра=( как бы хотелось, чтоб был стандартный апи, например как в оффтопике или солярке и модули можно было тащить из старых версия, просто копируя в новый каталог.. мечты, мечты.. наверное никогда не сбудуцца, даже с подобными костылями

>это наверное самое большое бедствие для всех пользователей пенгвинов, после каждого обновления, пересобирать все модуля ядра=( как бы хотелось, чтоб был стандартный апи, например как в оффтопике или солярке и модули можно было тащить из старых версия, просто копируя в новый каталог.. мечты, мечты.. наверное никогда не сбудуцца, даже с подобными костылями

пользователи пЕнгвинов - это, простите, кто такие? тюлени из Арктики чтоли?!

Нет, а идея-то, довольно неплохая, хоть и не новая.. Другое дело, что в реальности реализация идеи не всегда отражает теоретические плюсы.. Однако, в любом случае, хуже от этого никому не будет..

Угу... Новая порода. Антогонист старой, которая из Антарктики. ;-))

Вобщем главный плюс чикаги - она будет скачивать недостающие драйвера сама.

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

И далеко не факт, что он соберётся и заработает так, как надо - если поменяли стек, стратегию выделения памяти и пр. ABI - фигня, решается перекомпиляцией, а вот если поменяли API и какую-то схему внутриядерного взаимодейтвия - глюки можно вылавливать месяцами, и нет гарантии, что оно после этого корректно заработает...

>Не знаю у кого как, но у меня после загрузки нового ядра зачем-то сносит модуль из старого.

Ну дружок, это ты врёшь. Ничего там не сносится. Не работает-это да. Но остаётся в целости и сохраности. А драйвер есть модуль ядра. И собирается вместе с ядром или под ядром. Глупо требовать, что бы модуль одного ядра работал под другим.

А стоит ли так гнаться за обновлениями ядра?

Елы-палы, окей стандартизованный ABI - глюки, пусть, но API то стандартный для сторонних драйверов ну нужен ведь, ну сколько можно ядра-то пересобирать??? бессмысленная работа отнимающая кучу времени и сил. надоели эти kernel-разработчики - перекладывают с больной головы на здоровую уже который год.

в свете последних событий и заявлений (http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-...), предрекаю -- еще до конца года Линус скажет что был неправ и linux 3.0.0 будет порезан на модули, между которыми будет как минимум стабильный api.

mcedit /usr/src/linux/Documentation/stable_api_nonsense.txt

кстати зачем ты ядра пересобираешь ?

> Линус скажет что был неправ....стабильный api.
Я бы с тобой поспорил на 2000$, если бы мы были знакомы в реале...

>> Линус скажет что был неправ....стабильный api. > Я бы с тобой поспорил на 2000$, если бы мы были знакомы в реале...

ну на $2000 я не уверен, а вот на $200 -- есть некоторая надежда :-) нет, спорить не буду.

> в свете последних событий и заявлений [...] и linux 3.0.0 будет порезан на модули, между которыми будет как минимум стабильный api.

Дык це ж будет шаг к микроведру. Вот Таненбаум-то потравит...

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

Для примера, попробуйте прикрутить дрова от AverMedia, которая выпустила бинарные драйвера для ядра 2.6.10 (если мне не изменят память) и скзала что другие версии выпускать не собирается. Попробуйте их прикрутить к последнему ядру.

>хм, у меня уже 100 лет стоит... %)

Столкнулся с DKMS, когда делал iSCSI Target месяц назад. Сначала даже не понял, что за фигня, потом обрадовался идее. После пересборки SRPM'а получилось два пакета - собственно сам iscsitarget и dkms-iscsi_trgt. В fc7 DKMS собирает модули при загрузке.

Лично у меня проблема постоянной пересборки модулей возникла ещё в те времена, когда драйвер для cxacru не шёл в комплекте с ядром. Мало того, что пришлось изначально патчить исходники на предмет поддержки ID для попавшей ко мне версии модема Zyxel Omni ADSL USB, так ещё и гарантированная пересборка при обновлении ядра...

А на домашней машине это тоже нужно. Обновил kernel-2.6.22.1-41 на kernel-2.6.22.5-76 - пересобирай драйвер NVidia. Что, API поменялось? НЕТ.

Так что DKMS - вполне полезная вещь.

> но API то стандартный для сторонних драйверов ну нужен ведь

Вот примерно каково мнение разработчики ядра: "напишите драйвера, откорйте их под GPL, тогда мы их включим в ядро и сами будем париться". Иными словами, они вообще не хотят, чтобы были сторонние драйвера.

Вопрос к людям которые имеют отношение к разработке ядра - в чем проблема сделать внешний стабильный api?

Да причём тут стабильный или не стабильный API? Вы головой подумайте - меняется внутренняя структура ядра, повторюсь: меняются *.h файлы и там где раньше был struct htd *note; теперь, извините, ничего нет переехало! Или вообще ту ветку которая раньше обрабатывала ваше устройство обобщили с другими, не только переназывали поля, а изменили логиу работы с ними. Как программист программисту скажите, что делать в таком случае? Пока нет ИИ вы будете сами ручками дотачивать свои модули до соответствия конкретному ядру. Вы же не хотите чтобы компьютер заменил программиста? Если станет возможна эта автоматизация, то готовтесь к skynet.

Или можно за счёт производительности действительно запретить всё менять и обходиться старыми средствами. Это как если бы с появлением DMA все обмены всё равно шли бы через CPU потому что всё уже зафиксировано.

> в чем проблема сделать внешний стабильный api

Documentation/stable_api_nonsense.txt

> как бы хотелось, чтоб был стандартный апи, например как в оффтопике или солярке и модули можно было тащить из старых версия, просто копируя в новый каталог

Чоо? о_О
Это т.е. можно обновив ядро с XP на Vista, просто скопировать файлики из старой system32 и они будут нормально работать??

>>Чоо? о_О Это т.е. можно обновив ядро с XP на Vista, просто скопировать файлики из старой system32 и они будут нормально работать??

ну многие драйверы подходили и для 2000 и для хр, не говоря про обновления типа сп1, сп2. а в некоторых случаях и от 95, 98 подходили в линейке 2000, хр (пример длинк дсл200, драйвер универсальный от всех виндов) а у солярки некоторые модули подходят и из 7,8 версий. здесь же, при переходе летом с 2.6.20 на 2.6.21 я был вынужден перебирать нвидию, лтмодем, ралинк, квм, вмваре и может что-то ещё, что уже не помню. ещё хуже был переход с 2.4.32 на 2.6.20, многие привычные модули не захотели собирацца. про вмваре было найдено что из за изменений апи в 2.6.20 надо вносить патч, но в 2.6.19 всё собиралось чудесно, так же пришлось высасывать новые исходники от ралинка, лтмодема. теперь ес-нно мне вовсе не хочецца снова прыгать с бубном, перебирая все модули снова переходя на 2.6.22. и не выход использовать что-нибудь типа "паебунты" или "сусе", в которую входит много закрытых дров, не всегда они есть в комплекте, например ралинковский драйвер в "поебунте" из комплекта, вешал систему если грузицца с воткнутым вай-фаем (д-линк г122). пересобранный снова драйвер решал эту проблему.

речь помоему шла не о "подходили", а о потребности в пересборке/переустановке. При смене версии ядра в windows, с NT4 на NT5 например, точно также требуется переустанавливать все драйвера.

к слову, драйвера той же нвидии у меня отлично подходят к разным подверсиям ядра.

Из своего опыта, скажу напротив, что подавляющее большинство драйверов от 9x не подходят к NT

ЗЫ: затесалось подозрение, что у вас LFS %)

>Это т.е. можно обновив ядро с XP на Vista, просто скопировать файлики из старой system32 и они будут нормально работать??

Да понятно, если при смене мажорной версии нужно переставить ВСЕ дрова. Но почему минорная смена ломает систему и мне нужно пересобирать дровишки??? Особенно когда производитель дал бинарный драйвер только к определенной версии :(

ИМХО лучше чтобы смена 2.6.20 -> 2.6.21 -> 2.6.22 проходила БЕЗ пересборки. Пока тут ведет Винда, где смена минора не требует перустановки дров.

> Documentation/stable_api_nonsense.txt

политика..

Блин да вы читайте выше, задолбали. Ну нет в ядре мистики - формализованная логика одна. Ну нельзя ничего не меняя что то менять!! Ну поймите, ну нельзя, это противоречит законам нашей вселенной. Ну если меняется структура которой обмениваются функции по указателю, ну нельзя не пересобрав всех клиентов этой структуры дать им понять что она поменялась. Если вы не разработчик - поверте на слово. Не надо мистификаций - де не хотят программисты и всё тут. Не могут!! Это физически не возможно. Информация должна откуда-то взяться. Единственно как можно незаметно для пользователя сделать вид что модуль подходит всем ядрам это сделать кучу #ifdef. Или кучу отдельный вариантов внутри самого модуля, но те кто их может написать знают какой это ужос.

> Ну нельзя ничего не меняя что то менять!!

и это тоже политика..

совсем нет необходимости менять столь часто базовые вещи в stable-ядрах.

> политика

Идите в Windows. Пожалуйста.

> ну многие драйверы подходили и для 2000 и для хр, не говоря про обновления типа сп1, сп2. а в некоторых случаях и от 95, 98 подходили в линейке 2000, хр (пример длинк дсл200, драйвер универсальный от всех виндов)

О, народ, вы ведь даже во внутренностях Windows не сечёте.

1) Драйвера от Win 9x подходят к NT >= 5.0, только если полностью написаны с соблюдением стандарта WDM

2) Драйвера, написанные исключительно для NT 5.0 (2000), не подходят для Windows XP

3) Драйвера от XP большей частью (> 5%) не подходят для Vista

Короче, в сад!

s/5%/75%/

> Идите в Windows. Пожалуйста.

может быть..

>>речь помоему шла не о "подходили", а о потребности в пересборке/переустановке. При смене версии ядра в windows, с NT4 на NT5 например, точно также требуется переустанавливать все драйвера.

при смене ос, да, но не при установке сервиспаков для одной из веток нт.

>>ЗЫ: затесалось подозрение, что у вас LFS %)

нет, слакварь, как очень похожая по логике на бсд=)

>>Блин да вы читайте выше, задолбали. Ну нет в ядре мистики

ну у других ос это получилось? тот же сторонний драйвер для макосХ, требует например 10.2 или выше версию. и _работает_ на любых обновлениях и на 10.2 и на 10.3.х и на 10.4.х.

>>О, народ, вы ведь даже во внутренностях Windows не сечёте.

вы не поверите, но не все люди девелоперы и даже не быдлокодеры. есть и другие специальности..

>>Короче, в сад!

кончились аргументы, поэтому посылаете? есть реальные факты, что работает в других юникс системах, солярис и масосьХ, как минимум у которых старые драйвера не надо пересобирать, можно просто подсунуть старые и будет всё работать.

естественно, толку с этого "спора" нету, всё равно ничего не изменицца, раз уж 16 лет пенгвин существует с таким "физическим недостатком", так и будет дальше продолжацца.

> Ну если меняется структура которой обмениваются функции по указателю, ну нельзя не пересобрав всех клиентов этой структуры дать им понять что она поменялась. Если вы не разработчик - поверте на слово.

Это лишь в случае, если меняется апи непосредственно связанное с моим модулем. это понятно.
Непонятно почему когда в ядре поменялись допустим только функции вин-модемов и файловых систем, а меня просят пересобирать видеодрайвер? о_О