http://unix.ginras.ru/linux/base004.html

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

От редактора: на всички заинтересовани предлагам да изпращат своите впечатления и съображения по нетривиалните опции на ядро 2.6

Алексей Федорчук.

А нямаше да е зле да се прочете, какви са новостите в ядро 2.6. ...

Но тъй като въобще не се получава (или разсъжденията са прекалено общи, или обратно – прекалено специализирани), остана да се заема сам с надеждата, че някой по редицата ще каже нещо интересно.

Въобще, в ядро 2.6 има немалко новости. Реалността е такава, че е добре всички те да бъдат тествани: принципните усъвършенствания – за оценка на идеята и реализацията, допълнителните – за начина на изпълнение. Под принципни, в дадения случай, се разбират възможностите (features), продиктувани от логиката на развитие на ядрото, докато допълнителните са тези, “дошли” от съществували по-рано независими проекти. Това деление донякъде е условно, но в някои случаи и полезно.

За съжаление, усъвършенстванията от “втори род” имат не по-малка нужда от тестване, отколкото и собствените разработки на “ядрените” разработчици. Причините за това са очевидни: работоспособният (като правило) проект трябва да се модифицира дотогава, докато се постигне пълно съответствие с новото положение на ядрото. Модификацията засяга и кода, и документацията. А дали има нещо по-тягостно за програмиста от модификация на напълно работоспособен продукт. Ако има такива неща, те не са много.

За ядро 2.4 съществуваше проекта pcmcia, но след два дена експерименти, все пак бях принуден да се откажа от модула yenta_socket, предлаган от ядрото в полза на модула i82365 от pcmcia-cs-3.2.4. Трябва да призная, че “по-доброто” е враг на “хубавото”, поне понякога.

И в този случай ще стане дума за едно от усъвършенстванията от “втори род” - интеграцията в ядрото на проекта lm_sensors. Този проект скоро ще навърши шест години и е напълно работоспособен. Но е невъзможно да не признаем, че за всеки проект, включващ в себе си създаване на модули за ядрото, интеграцията с ядрото ще е от полза. Друг въпрос е доколко безболезнена ще бъде тази интеграция. И именно за нея ще говорим.

Ако някой още не се е сетил – lm_sensors е проект за поддържане на мониторинг [1] на оборудването (температура, обороти на въртене на вентилаторите, напрежение на захранването). Този мониторинг се осъществява чрез обмен по шината SMB (system Management Bus). Освен чиповете за мониторинг, към тази шина могат да бъдат свързани и чиповете EEPROM на съвременните модули памет. Чипове за мониторинг и датчици в момента се поставят не само на дънните платки, но и самите процесори [2] и на някои видеокарти. Доколко е необходим такъв мониторинг въобще – това се решава от всеки собственик на персонален компютър, но безспорно, за сървърите и технологичните компютри, това практически е стандарт.

В света на MS Windows, мониторинга на оборудването е почти винаги инициатива на самите производители на същото това оборудване. С всички произтичащи от това последствия – незадоволително до момента качество на програмното осигуряване, липса даже на намек за стандарт, орязана функционалност. Комерсиалните и свободни програми за следене на оборудването не са много.

Ситуацията в Linux се разви малко по-различно. Това, че мониторинга изисква действия на ниво ядро нито е хубаво, нито е лошо – такава е реалността. Това, че група ентусиасти се е заела да реализира единен подход към него, осъществяван с помощта на десетки различни датчици и чипове е много хубаво. А това, че в крайна сметка този мониторинг се превърна в “естествено” умение на ядрото е прекрасно. Съгласете се, че възможността да получите данните от мониторинга някъде от /sys/proc... е най-доброто, което може да се очаква. Тези данни могат да се визуализират във произволна форма, да се протоколират, включват във “вериги” за обратна връзка и т. н.

С една дума, идеята е добра. Остава да оценим реализацията, което предлагам да направят всички, четящи тези редове. А за да отнеме експеримента колкото е възможно по-малко време, прилагам следната кратка инструкция, която по никакъв начин не е опит да замени или допълни много качествената документация на проекта. Просто тази документация в голяма степен е ориентирана на операции с по-ниски версии на ядрото (под 2.5). И е малко голяма, ако мониторинга не е жизнено необходим, а просто ни е “интересно”. И така:

• За ядрото – разбира се, трябва да бъдат компилирани всички модули, имащи отношение към i2c. След версия 2.5, както беше казано, всички модули на нужните драйвери са част от самото ядрото.

• След уточняване на версията на ядрото, трябва да се отиде на сайта на проекта и да се уточни каква версия на lm_sensors се препоръчва да се използва с конкретното ядро. Това, че даже и при наличие на всички необходими драйвери, все още е необходим пакета lm_sensors, не трябва да изненадва – всички потребителски програми за настройка и диагностика не са част от ядрото. Дистрибуцията lm_sensors не е голяма (по-малко от 1 MB), така, че няма нищо страшно.

• Ако в системата не се използва директория /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. А ако резултата е “нулев” тогава имаме два варианта за действие:

• не правим нищо, оправдавайки се с нeвъзможността Linux да наблюдава нашата система;

• започваме да четем вече споменатата с добро документация на проекта – в действителност, в ядрото 2.6 засега е включена само малка част от разработените драйвери. Ако необходимият драйвер е останал в по-голямата част се предлага да се портне самостоятелно или да се почака, докато някой друг го направи.

Наскоро се появи и малък подарък – в директорията prog/pwm се намира скрипта pwmconfig, който позволява да определите дали вашата дънна платка има възможност да регулира скоростта на въртене на вентилаторите. Ако отговора е “да”, тогава скриптът fancontrol[.pl] може да осъществява автоматично тази регулация.

превод: Николай Ангелов

[1] Не можах да се сетя за друга дума, която недвусмислено да отразява това, което се иска да се прави, затова се извинявам за предизвикания лек дискомфорт сред привържениците на чистия български език.

[2] Има се предвид CPU – централният процесор на машината.

<< Напълно автономно делегиране на in-addr.arpa | Инсталиране на SuSE Linux 9.1 [Част 3] >>