Дослідження і тестування системи

У міру того, як ви будете накопичувати досвід у налагодженні ядра, у вас буде зявлятися все більше маленьких хитрощів, які допомагають у дослідженні та тестуванні ядра для отримання відповідей на питання, що цікавлять Так як налагодження ядра вимагає великих зусиль, то кожен маленький рада, або хитрість може виявитися корисним Розглянемо кілька таких хитрощів

Використання ідентифікатора UID в якості умови

Якщо розробляється код повязаний з контекстом процесу, то іноді зявляється можливість виконати альтернативну реалізацію не «ламаючи існуючий код Це важливо, якщо необхідно переписати важливий системний виклик і при цьому необхідна повністю функціонуюча система, на якій цей виклик треба налагодити Наприклад, припустимо, що потрібно переписати алгоритм роботи системного ви-

поклику fork (), який би використовував деякі нові можливості, які вже існують в ядрі Якщо відразу не вийде все зробити так як треба, то буде дуже важко налагоджувати ядро, так як непрацюючий системний виклик for k () швидше за все призведе до непрацездатності системи Але як і завжди, є надія

Часто безпечним буде зберегти старий алгоритм, а нову реалізацію виконати в іншому місці Цього можна досягти використовуючи ідентифікатор користувача (UID) як умови того, який алгоритм використовувати

if (current-&gtuid = 7777) {

/ * Старий алгоритм . * /

} else {

}

/ * Новий алгоритм . * /

lice користувачі, крім того, у якого ідентифікатор UID дорівнює 7777 будуть використовувати старий алгоритм Для тестування нового алгоритму можна створити нового користувача з ідентифікатором 7777 Це дозволяє більш просто оттестировать критичні ділянки коду, повязані з виконанням процесів

Використання умовних змінних

Якщо код, який ї необхідно протестувати, виконується не в контексті процесу, або необхідний більш глобальний метод для контролю нових функцій, то можна використовувати умовні змінні Цей підхід навіть більш простий, ніж використання ідентифікатора користувача Необхідно просто створити глобальну змінну і використовувати її в якості умови виконання того, чи іншої ділянки коду Якщо значення змінної дорівнює нулю, то слід виконати одну ділянку коду Якщо змінна не дорівнює нулю, то виконується іншу ділянку Значення змінної може бути встановлено за допомогою відладчика, або спеціального експортованого інтерфейсу

Використання статистики

Іноді необхідно отримати уявлення про те, наскільки часто відбувається деяка подія Іноді потрібно порівняти кілька подій і обчислити характеристики для їх порівняння Це дуже легко зробити шляхом введення статистки і механізму для експортування відповідних параметрів

Наприклад, припустимо, що необхідно зясувати на скільки часто відбувається подія foo і подія bar У файлі вихідного коду, в ідеалі там, де відповідні події виникають, вводиться дві глобальні змінні

unsigned long foo_stat = 0

unsigned long bar_stat = 0

Як тільки настає цікавить подія, значення відповідної змінної збільшується на одиницю Ці змінні можуть бути експортовані як завгодно Наприклад, можна створити інтерфейс до них через файлову систему / ргос, або написати свій системний виклик Найбільш просто прочитати їх значення за допомогою відладчика

Слід звернути увагу, що такий підхід принципово не безпечний на

SMP машині В ідеалі необхідно використовувати атомарні змінні Однак,

для тимчасової статистики, яка необхідна тільки для налагодження, ніякого захисту звичайно не потрібно

Обмеження частоти проходження подій при налагодженні

Часто необхідно вбудувати в код налагоджувальні перевірки (з відповідними функціями виведення інформації), щоб візуально робити моніторинг проблеми Однак, в ядрі деякі функції викликаються по багато разів в секунду Якщо в таку функцію буде вбудований виклик функції print k (), то системна консоль буде перевантажена висновком налагоджувальних повідомлень і її буде неможливо використовувати

Для запобігання такої проблеми існує два порівняно простих прийому Перший – обмеження частоти проходження подій – дуже корисний, коли необхідно спостерігати, як розвивається подія, але частота виникнення події дуже велика Щоб обмежити потік налагоджувальних повідомлень, ці повідомлення виводяться тільки раз на кілька секунд, як це показано в наступному прикладі

static unsigned long prev_jiffy = jiffies / * Обмеження частоти * /

if (time_after (jiffies, prev_jiffy + 2*HZ)) {

prev_jiffy = jiffies

printk (KERN_ERR &quotblah blah blah\n&quot)

}

У цьому прикладі налагоджувальні повідомлення виводяться не частіше, ніж один раз на дві секунди Це запобігає перевантаження консолі повідомленнями і системою можна нормально користуватися Частота висновку може бути більшою, чи меншою, залежно від требопаній

Друга ситуація має місце, коли необхідно помічати будь появи події На відміну від попереднього прикладу немає необхідності виконувати моніторинг розвитку подій А тільки отримати повідомлення про те, що щось сталося Ймовірно це повідомлення необхідно отримати один, або два рази Проблема виникає в тому випадку, якщо перевірка, яка після того, як спрацювала один раз, починає спрацьовувати постійно Рішенням в даному випадку буде не обмеження частоти, а обмеження загальної кількості повторень

static unsigned long limit = 0

if (limit &lt 5) {

limit++

printk(KERN_ERR &quotblah blah blah\n&quot)

}                                            ,

У цьому прикладі кількість налагоджувальних повідомлень обмежено числом пять Після пяти повідомлень умова завжди буде хибно

В обох прикладах змінні повинні бути статичними (static) і локальними по відношенню до тієї функції, де використовуються Це дозволяє використовувати однакові імена змінних в різних функціях

Жоден з цих прикладів не розрахований на SMP, або преемптівность, хоча дуже легко перейти до атомарним операціями і зробити їх безпечними для використання і в цих випадках Однак, чесно кажучи, це всього лише відладочний код, тому навіщо потрібні зайві проблеми

Джерело: Лав, Роберт Розробка ядра Linux, 2-е видання : Пер з англ – М: ТОВ «ІД Вільямс »2006 – 448 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*