CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
25.10.2021

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Desktop
Internet
Internet-серверы
Безопасность
Бизнес/Офис
Игры
Мультимедиа
Наука
Операционные системы
Программирование
СУБД
Создание веб-сайтов
Утилиты

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

lm_sensors и ядро Linux 2.6

А неплохо бы почитать, что нового в ядре 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, как уже сказано, все модули необходимых драйверов - часть дистрибутива ядра.
  • Затем, уточнив версию своего ядра, следует сходить на сайт проекта и уточнить: какую версию 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] может эту регуляцию осуществлять автоматически.





Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds