[мысли вслух][kernel][deviceid] а почему не сделают....

А при загрузке модуля средствами modprobe нельзя передать?
(Сам не в курсе)

Вот линуксоиды прозрели .inf-файлы из вантуза)
Если серьезно, идея неплоха, хотя я с подобными вещами не сталкивался.

Недавно писал, что в опенсоплярисе так и есть. Есть файлик /etc/driver_aliases и там прописаны соответствия между deviceid и модулями ядра.
Но лялекс же демонстрирует классический прием говнокодинга - хардкодинг констант.

Через sysfs можно прибиндить драйвер к девайсу, но это не всегда срабатывает. Ну и порой для разных девайсов нужно использовать где-то разную логику, поэтому не всегда просто дописывание idов в исходник является правильным (полностью) способом.

>Вот линуксоиды прозрели .inf-файлы из вантуза)
Если подходить без лишнего фанатизма.... и продвигать систему "в массы" то что то подобное потребуется.
Вот я как то не натыкался на человеческую базу оборудования поддерживаемого Linux....

Аналогично в макоське, но там кошернее, конфиги для каждого модуля в отдельных файлах, емнип, - /System/Library/Extensions/blabla.kext/Content/Info.plist

Согласен что не совсем правильным - но опять же - "а вдруг заработает?"
Ну и тем более когда оно и действительно работает - а в исходних табличка на 5-10 устройств - и никаких условий и прочих зависимостей.

> Вот линуксоиды прозрели .inf-файлы из вантуза)

Чукча не читатель, чукча писатель? Для любых более-менее сложных драйверов (то есть для всех кроме "драйверов модемов") в INF-файле содержится PCI ID устройства и ссылка на бинарник. В линуксе эти данные содержатся в бинарнике драйвера и экстарктятся в /lim/modules/`uname -r`/modules.pcimap

> Если серьезно, идея неплоха, хотя я с подобными вещами не сталкивался.

Если серьезно, может вам сначала поспрашивать у более грамотных товарищей? :-)

1 вопрос: ты отписал ядерщакам, что у тебя такой-то девайс после этого с таким-то модулем поднялся? Если нет - быстро убежал отписываться.

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

Это не логично, это называется "говнокод".

Представь, что модуль поддерживаешь некоторый набор устройств, работа с которыми несколько отличается. Как он будет знать, как именно работать с не известным айдишником? Или предлагаете вынести в конфиги не только айдишники, но и часть логики модуля?

Подожди. Инфа о том, что поддерживается драйвером ВЕСЬМА связана с самим драйвером, т.к. это его дело. И модифицируя драйвер, разработчик САМ добавляет девайс в список поддерживаемых.

Что не так?

>Это не логично, это называется "говнокод"

Т.е. вы принципиально не используете константы, а все читаете из файлов настроек?

http://code4food.ru/?p=29

>1 вопрос: ты отписал ядерщакам, что у тебя такой-то девайс после этого с таким-то модулем поднялся? Если нет - быстро убежал отписываться.

Вот озвученный вопрос и возник в тот момент - когда скачал новое ядро - и увидел то, что надо заново дописывать эти жалкие пару строк....

А кому писать - не представляю =) , теоретически предпологаю что в начале исходника указан email того, кто за него отвечает....просто не вчитывался.

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

>А кому писать - не представляю =) , теоретически предпологаю что в начале исходника указан email того, кто за него отвечает....просто не вчитывался.

Да, отпиши ему, пожалуйста. Простого способа нет, т.к. это очень редко, когда старый драйвер пашет с новым девайсом.

Если я глупость сказал, то извиняй. Но разве ТС не предложил действительно нечто очень похожее на то что ты описал?

Мимо. Это не константа, а жесткое кодирование переменной по сути величины. deviceid же по сути - константа.

>что вот этот модуль ядра держит устройство с таким то deviceid

Это отдельное тестирование. Кто его будет проводить, кто его будет проверять? Где гарантия, что работать он будет не в штатном режиме, а, скажем, с перегрузом и сдохнет за неделю?

>Где гарантия, что работать он будет не в штатном режиме

То есть, наоборот, конечно.

Не хватало еще одной зависимости от user space. deviceid - константы и файл конфигурации для них не нужен, ради 0,01% случаев, когда не все id туда вписаны.

Я вот думаю очень характерным будет файлик patch_nvhdmi.c,
который(судя по заголовку) ведёт сама nvidia - в нём только 5 deviceid.... но вот почему то у меня такое ощущение - что он подойдёт к гораздо большему числу видеоплат на базе GPU nvidia.... - хотя это только мои домыслы

да, но доводить до «Мягкого кодирования» тоже нельзя!!

Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование.

см. http://ru.wikipedia.org/wiki/Антипаттерн

можно просто на lkml тред завести.
типа: сделал то-то. девайс работает. в dmesg чисто. может ли кто сделать патч?

Это не логично, это называется «говнокод».

Нет. Это называется «инкапсуляция» данных и поведения == ООП, одним словом. Не зря же придумана парадигма модулей в виде классов.

да, но доводить до «Мягкого кодирования» тоже нельзя!!

+1000000

То, что люди имеют, используя J2EE, — это кодирование на XML, в основном. :))))))

>можно просто на lkml тред завести.

Даешь! Всем ЛОРом будем отписываться. Интересно, кто кого затроллит - ЛОР Линуса или наоборот?

Чегооо? При чем тут ООП? А если уж говорить про ООП, то там есть такое понятие как "настраиваемые классы" ;)

Правильно думаешь, почти наверняка nvidia зарезала многие хардварные возможности на уровне драйверов.
Вспоминаю, что можно было под виндой "переделывать" GeForce до Quadro. Виндовым дровам подсовывали патченый .inf и вуаля! У видеокарты ВНЕЗАПНО появлялись новые фичи, вроде аппаратного рендеринга тумана.

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