Но, поскольку никак не получается (то слишком общие рассуждения, то,
напротив, узкоспециализированные), остаётся заняться этим самому. В
надежде на то, что кто-нибудь "алаверды" скажет что-то и тебе
интересное.
Вообще, новостей в 2.6 немало. Реальность такова, что хорошо бы их все
тестировать: принципиальные усовершенствования - на предмет оценки
идеи и реализации, дополняющие - на предмет исполнения. Под
принципиальными, в данном случае, подразумеваются фичи (features),
продиктованные логикой развития собственно ядра, тогда как дополняющие
- те, что "пришли" из проектов, существовавших ранее независимо.
Деление, конечно, условное, но, в некоторых случаях, полезное.
К сожалению, усовершенствования "второго рода" нуждаются в
тестировании не менее, чем собственные разработки "ядерщиков". Причины
очевидны: работоспособный (как правило) проект, нужно модифицировать
вплоть до соответствия его новому, "ядерному", положению. Модификация
затронет и код, и документацию. А есть ли для программиста что-то
более тягостное, нежели модификация вполне работоспособного продукта?
Если и есть, то - немного.
Так, в ядре 2.4 получил прописку проект pcmcia, но после двух дней
экспериментов я всё-таки был вынужден отказаться от от модуля
yenta_socket, предлагаемого ядром, в пользу модуля i82365 из
pcmcia-cs-3.2.4. Приходится признать, что "лучшее - враг хорошего". По
крайней мере - иногда.
И в данном случае речь пойдёт об одном из усовершенствований "второго
рода": интеграции в ядро проекта lm_sensors. Проекту lm_sensors скоро
будет шесть лет и он вполне работоспособен. Невозможно, однако, не
признать, что любому проекту, включающему в себя создание модулей
ядра, интеграция с последним будет на пользу. Другое дело, насколько
безболезненной будет эта интеграция... О ней-то и речь.
Если кто-то ещё не догадался: lm_sensors - проект поддержки
мониторинга оборудования (температура, вращение вентиляторов,
напряжения питания). Мониторинг этот осуществляется посредством обмена
по шине SMB (System Management Bus). Кроме чипов мониторинга к этой
шине могут быть подключены чипы EEPROM современных модулей памяти.
Чипы мониторинга и датчики в настоящее время располагаются не только
на M/B, но и на CPU и некоторых видеокартах. Насколько такой
мониторинг нужен вообще - каждый обладатель персонального компьютера
вправе решать сам, но, несомненно, что для серверов и технологических
компьютеров это, практически, стандарт.
В мире MS Windows мониторинг оборудования - почти исключительно
инициатива производителей оборудования. Со всеми вытекающими отсюда
последствиями: неудовлетворительное, подчас, качество ПО, отсутствие
даже намёка на стандарт, усечённая функциональность. Коммерческие и
свободные программы мониторинга довольно немногочисленны.
Несколько иное положение сложилось в Linux. То, что мониторинг требует
действий на уровне ядра - не хорошо и не плохо: это - реальность. То,
что группа энтузиастов взялась реализовать единый подход к
мониторингу, осуществляемому с помощью десятков различных датчиков и
чипов - очень хорошо. А то, что в конечном счёте это стало
"естественным" умением ядра - прекрасно. Согласитесь, что возможность
получить данные мониторинга откуда-нибудь из /sys/proc... - лучшее,
что можно было ожидать. Эти данные можно визуализировать в любой
желаемой форме, протоколировать, включать в "цепочки" обратной связи и
т.д. и т.п.
Словом, идея - хороша. Осталось оценить реализацию, что я и предлагаю
сделать всем, читающим эти строки. А чтобы эксперимент отнял по
возможности меньше времени, прилагаю коротенькую инструкцию.
Инструкция эта - отнюдь не попытка заменить или дополнить довольно
качественную документацию проекта. Просто эта документация пока в
большой степени ориентирована на операции с ядрами <2.5. Да и
великовата, если мониторинг - не насущная потребность, а просто
"интересно". Итак...
* Для ядра, разумеется, должны быть скомпилированы все модули,
имеющие отношение к i2c. После 2.5, как уже сказано, все модули
необходимых драйверов - часть дистрибутива ядра.
* Затем, уточнив версию своего ядра, следует сходить на сайт
проекта http://secure.netroedge.com/~lm78 и уточнить: какую версию
lm_sensors рекомендуется использовать с данной версией ядра.
То, что даже при наличии всех необходимых драйверов пакет, lm_sensors
всё же требуется не удивляет: все пользовательские утилиты настройки
и диагностики частью ядра не являются. Дистрибутив lm_sensors невелик
(менее 1MB), так что - ничего страшного.
* Если в системе каталог /usr/local/ не используется, нужно
отредактировать Makefile. На предмет определения переменной
PREFIX, разумеется: configure в дистрибутиве отсутствует.
* В соответствии с INSTALL, нам требуется только
make user; make user_install
* Для работы скрипта настройки sensors-detect, требуется наличие
устройств /dev/i2c*. Если в системе их нет, то достаточно
запустить prog/mkdev/mkdev.sh (путь указан относительно корня
дистрибутивного каталога lm_sensors) или загрузить модуль i2c-dev
(modprobe i2c-dev)
* Весь поиск и анализ поручим скрипту sensors-detect. При наличии
определённой неприязни к английскому, на все вопросы скрипта можно
категорически давить "Enter"
* Результатом работы скрипта будет вывод на экран строк, которые
рекомендуется перенести в соответствующие конфигурационные файлы
загрузки. Записать эти строки стоит, а переносить пока не
обязательно: сначала выясним, есть ли от этого всего толк. Кроме
того, скрипт создаст файл /etc/sysconfig/sensors, но файл этот
используется только скриптом /etc/rc.d/init.d/lm_sensors,
выполняющим функции демона, а вот запускать его или нет (и как) -
вопрос частный для вас и вашего дистрибутива.
* Стоит уточнить, имеются ли в /lib/modules/2.6.x/kernel/drivers
модули, которые порекомендовал вам загрузить sensors-detect.
Аппаратная база мониторинга, а, вслед за ней и проект развиваются
так бурно, что скрипт мог и отстать от реального состава
драйверов. Так, рекомендованный мне модуль w83627hf в настоящее
время не существует, зато модуль нынешний модуль w83781d
обслуживает, в том числе, и чип W83627HF
* Если всё запрошенное в наличии, можно выгрузить i2c-dev (если он
загружался):
rmmod i2c-dev
и выполнить предложенные команды. Что-то вроде:
Результат - на экране. На несоответствие текстов ожиданию внимания не
обращаем: настраивается в /etc/sensors.conf. А вот если результат
"нулевой"... Тут вариантов два:
* ничего не делать, посетовав на неготовность Linux "мониторить"
вашу систему;
* начинать читать уже добрым словом упомянутую документацию проекта:
на самом деле в ядро 2.6 включена пока меньшая часть разработанных
драйверов. Только вот портировать необходимый драйвер, если он
оказался в оставшейся большей части, предлагается самостоятельно.
Или: подождать, пока это сделает кто-то.
Напоследок: маленький gift. В каталоге prog/pwm есть скрипт pwmconfig,
который позволит определить, есть ли возможность у вашего M/B
регулировать скорость вращения вентиляторов. Если "да", то скрипт
fancontrol[.pl] может эту регуляцию осуществлять автоматически.
940 Прочтений • [lm_sensors и ядро Linux 2.6 (linux kernel hardware monitor)] [08.05.2012] [Комментариев: 0]
Vova
