ACPI daemon: started!

ACPI daemon: started!

Владимир Попов
2005.11.17

По долгу службы (АСУТП, причём не в смысле "управления предприятием", а в смысле "управления технологическим процессом": автоматическим производством или научным экспериментом, например) меня всегда интересовало взаимодействие аппаратной и программной частей вычислительной системы. Ну, если речь идёт о технологических компьютерах или встроенных системах, то документирование этого самого взаимодействия - прямая обязанность производителя: программисту остаётся только читать повнимательнее. Другое дело - IBM PC. Производители постоянно совершенствуют аппаратную часть (а куда денешься: конкуренция). Причём, как базовую (обеспечивающую основы архитектуры IBM PC), так и вспомогательную (всё, что должно улучшать работу вычислительной системы, хотя и не является обязательным для IBM PC "в чистом виде"). Вот только насколько "поспевают" за этим производители программного обеспечения...

Традиционно, поддержку "базовой" части обеспечивает ОС, тогда как о поддержке дополнительных возможностей заботятся обычно сами производители, да ещё отдельные энтузиасты. Причём, грань между "базовой" и "вспомогательной" частями достаточно размыта. Особенно, если принимать во внимание разные ОС. Так, плавно переходя к теме, отмечу, что столь распространённая Windows XP "считает", очевидно, сенсоры, размещаемые на m/b, видеокартах и HDD - "излишеством", тогда как поддержка тех же устройств в Linux имеется уже на уровне ядра (начиная с 2.6, правда).

LM-sensors, о поддержке которых в ядре 2.6 я, помнится, уже писал когда-то, - это, конечно, хорошо. Доступ к элементам контроля температуры и управления вентиляторами непосредственно через файловую систему: что может быть лучше? Любое приложение, способное читать и писать файлы (читай: просто - любое), может учитывать "состояние здоровья" системы. Не имеет значения наличие или отсутствие графической среды, пристрастие к определённому desktop-менеджеру: в любом случае работа с сенсорами затруднений не вызывает. Однако...

"Неймётся" инженерам. И вот уже ACPI (Advanced Configuration and Power Interface), ещё недавно известная только обладателям ноутбуков, всё чаще оказывается на десктопах, становится, практически, "стандартом-де-факто" и, при этом, "отбирает" у BIOS функции APM (Advanced Power Management), у lm-sensors - контроль за датчиками температуры, "обещает" заменить собой драйвера всех устройств, которые контролируют батареи, SMBus и встроенные контроллеры, обеспечить единую политику управления вычислительной системой. Впечатляет...

Правда, до этого "идеала" пока ещё далеко: и сама спецификация ACPI никак не остановится в развитии, и BIOS большинства десктопов поддерживает ACPI далеко не в полной мере. Тенденция, однако, налицо. Если вы - счастливый обладатель современного ноутбука, BIOS которого поддерживает ACPI, но понятия не имеет об APM, то знакомства с ACPI - не миновать, если же только десктопа (а современные десктопы имеют, обычно, ограниченную поддержку ACPI), то, вполне вероятно, информация об ACPI пригодится вам в ближайшем будущем.

Насколько же готовы современные ОС использовать этот самый "Усовершенствованный Интерфейс управления Конфигурацией и Питанием"?

В "актив" Windows XP можно занести неплохое использование "sleep state" (режимов энергосбережения). "Рабочий" режим S0 сменяется состоянием остановки S1 ("Stopgrant"), затем - S3 ("Suspend to RAM"), S4 ("Suspend to Disk") и, наконец, S5 - "Soft Off". Ядро Linux переход в S3/S4 обеспечивает, только начиная от версии 2.6. Возможно, потому, что в Linux и без ACPI существует SWSUSP (SoftWare SUSPend). Можно сожалеть о том, что проект SWSUSP так и не стал частью канонического ядра, но факт, что поддержка "sleep state" - не была для пользователей Linux самой заманчивой частью спецификации ACPI.

Спецификация эта, однако, регламентацией энергосбережения не ограничивается: много в ней интересного и помимо этого. И ядро Linux (старше, скажем, 2.4.28 или 2.6.12) кое-чем из этого уже умеет пользоваться. Попытаюсь проиллюстрировать на примере ноутбука HP Invent (он же - Compaq nx6110). Compaq, вообще-то, известен "неординарностью" своих компьютеров: не зря им приходится к имеющимся в Windows XP шести hal*.dll добавлять в поставке ещё один - свой. Так что "откажись" Linux работать с реализацией ACPI на данном ноутбуке - удивляться бы не пришлось. Однако... не отказался!

Разумеется, ядро должно быть собрано с поддержкой ACPI. Сделать это самому или воспользоваться ядром, предлагаемым мейнтейнером дистрибутива - дело вкуса. Что же касается выбора между 2.4 и 2.6, то если цель - использование "sleep state", альтернативы нет: 2.6, в остальном... В моём случае, например, ядро 2.4 продемонстрировало более адекватные результаты. Вывод: пробовать нужно.

Дальше - совсем просто, как и должно быть с подсистемами ядра. Переходим в каталог /proc/acpi и внимательно изучаем его содержимое. Просматриваем файлы наиболее привычным вам образом: cat, less или <F3> в mc. При наличии интереса, можно воспользоваться утилитами acpi или acpitool . Безусловно, "раз на раз" не приходится и может статься, что в вашей системе содержимое данного каталога окажется безынтересным, но в моём случае я узнал:

тип, ёмкость, пределы предупреждения и отказа батареи;
текущее состояние батареи;
количество контролируемых вентиляторов (не обязательно совпадающее с количеством вентиляторов наличных);
состояние вентиляторов;
количество и текущее состояние термодатчиков, предельные значения темпператур.

Согласитесь: неплохо для начала.

Вентиляторы, как выяснилось, управлялись аппаратно, а вот о том, что ядро "знает" подключен ли AC-adaptor, на сколько времени хватит заряда батареи, не пора ли дать процессору "остыть" и никогда мне об этом не сообщает - я узнал с возмущением. Явно нужен "демон", который следил бы за /proc/acpi и сообщал, если требуется вмешательство Homo Sapiens. И такой "демон", конечно, существует. С непритязательным именем acpid. Всего-то несколько десятков килобайт в исходных текстах. Берём. Собираем. Инсталлируем. Запускаем. В разных дистрибутивах по-разному - нет смысла детализировать.

В результате имеем каталог /etc/acpi, а в нём всего-то два файла: acpi_handler.sh и events/default. Из документации следует, что events/default и определяет работу "демона". Смотрим, что "внутри" и находим всего четыре строки (не считая комментариев). Строки:

     event=button power.*
     action=/sbin/init 0

Определяют, очевидно, требование, в соответствии с которым при нажатии кнопки "power" система переходит на runlevel 0 (другими словами - выключается). Это - понятно.

Строки:

     event=.*
     action=/etc/acpi/acpi_handler.sh %e

Означают ни что иное, как то, что все остальные события, отмечаемые, демоном обрабатывает скрипт acpi_handler.sh. Смотрим, что в нём... А ничего, практически. Кроме уже обработанного нажатия кнопки "power" (и зачем два раза, причём одинаково, обрабатывать одно и то же событие?), все остальные события всего лишь заносят в log строку:

     ACPI group $1 / action $2 not defined

Причём $1 и $2, по всей видимости, параметры, передаваемые скрипту непосредственно демоном. Интуитивно понятно: зная, что именно передаёт демон скрипту в том или ином случае, можно переписать этот амый скрипт "на своё усмотрение", но как узнать, что же именно он передаёт или какие хотя бы бывают события...

Ответ, как ни странно, прост: "демон" передаёт скрипту "всё, что имеет". Или, точнее, всё, что получил от ядра в качестве информации об acpi-событии. Что именно - нет смысла описывать: слишком разные пока бывают ACPI. Просто берём файл /var/log/acpid и изучаем его. Подстрока в двойных кавычках, следующая в протоколе за словом event (событие) - явно и есть набор параметров, передаваемых скрипту acpi_handler.sh. Поэкспериментировав с кнопками, адаптером питания и разрядом батареи, для своего конкретного случая я сделал следующие выводы:

вопреки содержанию acpi_handler.sh, количество передаваемых параметров соответствует не двум, а трём, или даже четырём. Умолчательная строка (на тот случай, если событие не обрабатывается специальным образом) должна бы в этом случае выглядеть так:
```
	logger "ACPI group $1 / action $2 prm1 $3, prm2 $4 is not defined"
	
```
события, генерируемые термодатчиками, наиболее многочисленны. Если их обработка не планируется, то можно "маскировать" их вводом в acpi_handler.sh строк:
```
	thermal_zone)
	;;
	
```
аналогично можно поступить с событиями, генерируемыми процессором:
```
	processor)
	;;
	
```
значащим параметром для событий, связанных с адаптером питания, оказался четвёртый. Если включение/выключение адаптера питания достаточно сопровождать звуковым сигналом и записью в системный протокол, то можно ограничиться вводом в acpi_handler.sh строк:
```
	ac_adapter)
	cat /opt/kde/share/sounds/KDE_Beep_ShortBeep.wav > /dev/dsp
	case "$4" in
		00000001) logger "AC ADAPTER is on"
		;;
		00000000) logger "AC ADAPTER is off"
		;;
	esac
	;;
	
```
события, возникающего при разряде батареи ниже предупредительного (warning) уровня не оказалось. Учесть вероятность такого события, однако, сложности не представляет, поскольку доступны и "design capacity warning" (/proc/acpi/battery/C171/info) и "remaining capacity" (/proc/acpi/battery/C171/state). C171, в данном случае, - индикатор батареи. По достижении "remaining capacity" предельного значения можно выдавать звуковой сигнал, инициировать выключение и т.п.: дальнейшее развитие ничем не ограничивается (viva open source!).

Возможность переводить компьютер в одно из энергосберегающих состояний, управлять режимом процессора, безусловно, сделали бы работу системы более совершенной. И хотя мне приходилось успешно использовать SWSUSP, в данном случае, я, пожалуй, склонен предпочесть ACPI. Даже различия в реализациях, не означают невозможности заставить работать ACPI должным образом, поскольку для Linux Intel предоставляет возможность самостоятельно изменять DSDT (Differentiated System Description Table). Это, однако, уже совсем другая задача. И значительно более трудоёмкая.

Легко и быстро фотоапараты nikon в Киеве . туры в болгарию