The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

lm_sensors и ядро Linux 2.6 (linux kernel hardware monitor)


<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: linux, kernel, hardware, monitor,  (найти похожие документы)
From: Владимир Попов <popov@ukrpost.net.> Date: Mon, 20 Jul 2005 14:31:37 +0000 (UTC) Subject: lm_sensors и ядро Linux 2.6 Оригинал: http://www2.ldc.net/~popov/2.6-sensors.html А неплохо бы почитать, что нового в ядре 2.6... Но, поскольку никак не получается (то слишком общие рассуждения, то, напротив, узкоспециализированные), остаётся заняться этим самому. В надежде на то, что кто-нибудь "алаверды" скажет что-то и тебе интересное. Вообще, новостей в 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 и выполнить предложенные команды. Что-то вроде: modprobe i2c-i801 modprobe i2c-isa modprobe eeprom modprobe w83781d /usr/bin/sensors -s * И, наконец, "финал апогея нашего апофеоза": sensors Результат - на экране. На несоответствие текстов ожиданию внимания не обращаем: настраивается в /etc/sensors.conf. А вот если результат "нулевой"... Тут вариантов два: * ничего не делать, посетовав на неготовность Linux "мониторить" вашу систему; * начинать читать уже добрым словом упомянутую документацию проекта: на самом деле в ядро 2.6 включена пока меньшая часть разработанных драйверов. Только вот портировать необходимый драйвер, если он оказался в оставшейся большей части, предлагается самостоятельно. Или: подождать, пока это сделает кто-то. Напоследок: маленький gift. В каталоге prog/pwm есть скрипт pwmconfig, который позволит определить, есть ли возможность у вашего M/B регулировать скорость вращения вентиляторов. Если "да", то скрипт fancontrol[.pl] может эту регуляцию осуществлять автоматически.

<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>

Ваш комментарий
Имя:         
E-Mail:      
Заголовок:
Текст:





  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor