[devel] Q: hwdatabase Vs. kernel pcimap

[devel] Q: hwdatabase Vs. kernel pcimap

[Anton D. Kachalov]

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

После некоторого шаманства произвёл на свет скрипт, который аналогично
getpciids из libhw-devel, выдаёт список соответствия
vendorID/productID(subvendor/subproduct) <=> ядерный модуль.
getpciids использует нахаченную базу соответствий из hwdatabase.
Модули в 2.6 ядрах итак прекрасно умеют сообщать, какие железки они
поддерживают. Исключение составляют шаблонные девайсы, например, uhci-hcd,
где принадлежность модуля к железке определяется по его классу. В
hwdatabase это нахачено в виде нескольких известных VID/PID.

К письму приложен скрипт mod2pciids, который имеет совместимость с
getpciids, если вызывать его с параметром "-s".
А так же diff между modules.map для первой стадии livecd/installer/...,
полученные в результате работы getpciids и mod2pciids соответственно.

Я считаю более верным использование pcimap от ядра, нежели некой базы.
Но для этого потребуется добавить некоторые железки в модули.
А ещё подумать на тему того, как быть с модулями, подобными uhci-hcd.
Возможно, придётся внести нахаченные VID/PID в aliases к соответствующим
модулям помимо существующих там wildcards.

--
mouse


[-- Attachment #2: mod2pciids --]
[-- Type: text/plain, Size: 866 bytes --]

#!/bin/sh

readonly PROG="${0##*/}"

show_usage()
{
	cat <<EOF
$PROG -f module-list
EOF
	exit
}

TEMP=`getopt -n $PROG -o f:,k:,s,h -l kernel:,short-list,help -- "$@"` ||
	show_usage
eval set -- "$TEMP"

short=
modulelist=
kernel=$(uname -r)
while :; do
	case "$1" in
		-f) shift; modulelist="$1" ;;
		-k|--kernel) shift; kernel="$1" ;;
		-s|--short-list) short=1 ;;
		-h|--help) show_usage ;;
		--) shift; break ;;
		*) show_usage ;;
	esac
	shift
done

[ "$modulelist" != "-" ] || modulelist=

sed -n 's,\(\.ko\)\?\(\.gz\)\?$,,; s,^\([[:alnum:]._-]\+\)$,^\1[[:space:]]\.\*,p;' $modulelist |
	egrep -x -f - /lib/modules/$kernel/modules.pcimap |
	sed 's,ffffffff,ffff,g; s, 0x\(0000\)\?, ,g' |
while read m v d sv sd foo; do
	printf %s "$v $d"
	[ "$sv" = 'ffff' -o -n "$short" ] || echo -n " $sv"
	[ "$sd" = 'ffff' -o -n "$short" ] || echo -n " $sd"
	echo " $m"
done

[-- Attachment #3: modules.map.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 3178 bytes --]

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton D. Kachalov]

On Mon, Apr 17, 2006 at 01:22:20PM +0400, Anton D. Kachalov wrote:
> Я считаю более верным использование pcimap от ядра, нежели некой базы.
> Но для этого потребуется добавить некоторые железки в модули.
> А ещё подумать на тему того, как быть с модулями, подобными uhci-hcd.
> Возможно, придётся внести нахаченные VID/PID в aliases к соответствующим
> модулям помимо существующих там wildcards.
Или, что идеологически верно, добавить поддержку wildcards в первую
стадию. Что позволит поднимать железо даже по классу.

--
mouse

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton Farygin]

Anton D. Kachalov wrote:
> On Mon, Apr 17, 2006 at 01:22:20PM +0400, Anton D. Kachalov wrote:
>> Я считаю более верным использование pcimap от ядра, нежели некой базы.
>> Но для этого потребуется добавить некоторые железки в модули.
>> А ещё подумать на тему того, как быть с модулями, подобными uhci-hcd.
>> Возможно, придётся внести нахаченные VID/PID в aliases к соответствующим
>> модулям помимо существующих там wildcards.
> Или, что идеологически верно, добавить поддержку wildcards в первую
> стадию. Что позволит поднимать железо даже по классу.
> 

Скорее последнее, чем первое. Ибо сейчас часть железок теряется.

И hwdatabase всё равно придётся использовать, правда по другому 
алгоритму (для добавления в blacklist модулей, которые сломаны /или опасны)

Rgds,
Rider

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton D. Kachalov]

On Mon, Apr 17, 2006 at 01:58:26PM +0400, Anton Farygin wrote:
> Скорее последнее, чем первое. Ибо сейчас часть железок теряется.
> 
> И hwdatabase всё равно придётся использовать, правда по другому 
> алгоритму (для добавления в blacklist модулей, которые сломаны /или опасны)
Я думаю, что всё-таки основным свойством hwdatabase должно являтся
_дополнение_ основной базы, а не её замена, как сейчас.
Т.ч. я думаю, что имеет смысл добавить поддержку class, а также
subproduct/subvendor в первую стадию и использовать предложенный мною
скрипт, вынеся его в отдельный пакет, без зависимостей на libhw. Ему после
допиливания, по сути, нужно будет только залезать в blacklists из
hwdatabase.

--
mouse

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton Farygin]

Anton D. Kachalov wrote:
> On Mon, Apr 17, 2006 at 01:58:26PM +0400, Anton Farygin wrote:
>> Скорее последнее, чем первое. Ибо сейчас часть железок теряется.
>>
>> И hwdatabase всё равно придётся использовать, правда по другому 
>> алгоритму (для добавления в blacklist модулей, которые сломаны /или опасны)
> Я думаю, что всё-таки основным свойством hwdatabase должно являтся
> _дополнение_ основной базы, а не её замена, как сейчас.

Да, именно так и планируется. Просто для первой стадии пока не было 
поддержки class и subproduct/subvendor.


> Т.ч. я думаю, что имеет смысл добавить поддержку class, а также
> subproduct/subvendor в первую стадию и использовать предложенный мною
> скрипт, вынеся его в отдельный пакет, без зависимостей на libhw. Ему после
> допиливания, по сути, нужно будет только залезать в blacklists из
> hwdatabase.

Или сделать ещё проще и добавить этот алгоритм в getpciids, что 
собственно уже давным давно планировалось сделать.

Что бы отказаться от скриптов.

Rgds,
Rider

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton D. Kachalov]

On Mon, Apr 17, 2006 at 03:20:51PM +0400, Anton Farygin wrote:
> Да, именно так и планируется. Просто для первой стадии пока не было 
> поддержки class и subproduct/subvendor.
Будет просто замечательно.

> Или сделать ещё проще и добавить этот алгоритм в getpciids, что 
> собственно уже давным давно планировалось сделать.
> 
> Что бы отказаться от скриптов.
От каких скриптов? Некоторые вещи намного лучше заскриптовать, нежели
писать на Це/ЦеПиПи.
Честно говоря, немного смущяет такое огромное число зависимостей у простой
программки: $ ldd /usr/bin/getpciids
        libhw.so.0 => /usr/lib/libhw.so.0 (0x00117000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0016d000)
        libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0x00377000)
        libfdisk.so.1 => /usr/lib/libfdisk.so.1 (0x00383000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x0038d000)
Их неоправданно много. А тулзень эта бывает полезной и без такого
количества библиотек.

--
mouse

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton Farygin]

Anton D. Kachalov wrote:
> On Mon, Apr 17, 2006 at 03:20:51PM +0400, Anton Farygin wrote:
>> Да, именно так и планируется. Просто для первой стадии пока не было 
>> поддержки class и subproduct/subvendor.
> Будет просто замечательно.

Здесь патчи приветствуются...

> 
>> Или сделать ещё проще и добавить этот алгоритм в getpciids, что 
>> собственно уже давным давно планировалось сделать.
>>
>> Что бы отказаться от скриптов.
> От каких скриптов? Некоторые вещи намного лучше заскриптовать, нежели
> писать на Це/ЦеПиПи.
> Честно говоря, немного смущяет такое огромное число зависимостей у простой
> программки: $ ldd /usr/bin/getpciids
>         libhw.so.0 => /usr/lib/libhw.so.0 (0x00117000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0016d000)
>         libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0x00377000)
>         libfdisk.so.1 => /usr/lib/libfdisk.so.1 (0x00383000)
>         libuuid.so.1 => /lib/libuuid.so.1 (0x0038d000)
> Их неоправданно много. А тулзень эта бывает полезной и без такого
> количества библиотек.

Т.к. она используется только при сборке образа, то собственно говоря 
наличие большого количества библиотек никак не мешает. Правда часть из 
них я действительно оторву (libfdisk, libuuid) и добавлю зависимость на 
libvolume_id.

Rgds,
Rider

Re: [devel] Q: hwdatabase Vs. kernel pcimap

[Anton D. Kachalov]

On Mon, Apr 17, 2006 at 04:54:32PM +0400, Anton Farygin wrote:
> Здесь патчи приветствуются...
Возможно, будут :)

> Т.к. она используется только при сборке образа, то собственно говоря 
> наличие большого количества библиотек никак не мешает. Правда часть из 
> них я действительно оторву (libfdisk, libuuid) и добавлю зависимость на 
> libvolume_id.
Я всё равно не понимаю, зачем использовать плюсовую прогу, когда можно
обойтись простым шельным скриптом в пять строчек

--
mouse