Знаходження виконуваних образів із змінами приводять до помилок

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

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

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

Далі, необхідно ядро, в якому гарантовано є дефект Для полегшення пошуку слід скористатися найбільш ранньою версією ядра, в якій є дефект Після цього починається пошук виконуваного образу, в якому зявилася помилка Розглянемо приклад Припустимо, що останнє ядро, в якому не було помилки-2411, а останнє з помилкою-2420 Починаємо з версії ядра, яка знаходиться посередині- 2415 Перевіряємо версію 2415 на наявність помилки Якщо версія 2415 працює, значить помилка зявилася в пізнішій версії Слід спробувати версію між 2415 і 2420, скажімо версію 2417 З іншого боку, якщо версія 2415 не працює, то тоді ясно, що помилка зявилася в більш ранній версії, і слід спробувати версію, скажімо 2-413 І так далі

Зрештою проблема звужується до двох ядер – одне з дефектом, а інше –

без У такому випадку є ясна картина змін, які привели до проблеми

Такий підхід позбавляє від необхідності перевіряти ядра всіх версій

Якщо ніщо не допомагає – зверніться до товариства

Можливо, ви вже випробували всі, що знали Ви просиділи за клавіатурою незліченну кількість годин, і навіть днів, а рішення все ще не знайдено Якщо проблема в основному ядрі Linux, то завжди можна звернутися за допомогою до людей зі спільноти розробників ядра

Коротке, але досить детальний опис проблеми разом з вашими знахідками, послане в список розсилки розробників ядра електронною поштою, може допомогти відшукати рішення Зрештою, дефектів ніхто не любить

Глава 20, Латки, розробка і співтовариство спеціально присвячена співтовариству розробників ядра і його основному форуму – списку розсилки розробників ядра Linux (Linux Kernel Mail List, LKML)

Переносимість

inux – переносима операційна система, яка підтримує велику кількість різних компютерних апаратних платформПереносимість-це властивість, яка вказує, наскільки легко можна перенести код, який виконувався на одній апаратній платформі, для виконання на іншій апаратній платформі (якщо взагалі це можливо) Відомо, що ОС Linux є переносимої операційною системою, оскільки її вжеперенесли(Портировали) па велику кількість різних апаратних платформ Проте переносимість не виникає сама по собі, для виконання вона вимагає великої кількості проектних рішень Сьогодні процес перенесення ОС Linux на іншу апаратну платформу досить простий (у відносному сенсі, звичайно) У цій главі розповідається про те, як писати стерпний код, – питання, про яке завжди необхідно памятати

при написанні нового коду ядра або драйверів пристроїв

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

З протилежного боку можна поставити операційні системи, в яких оптимізація коду виконується на шкоду переносимості Код, по можливості, пишеться на мові асемблера або специфічні властивості апаратних платформ використовуються яким-небудь іншим чином Властивості ядра розробляються на підставі властивостей апаратної платформи У цьому випадку перенесення операційної системи на іншу апаратну платформу зводиться до написання ядра з нуля Оптимальність виконується на шкоду переносимості Прикладом таких систем можуть бути DOS і Windows 9x Сьогодні таким системам немає необхідності мати більш оптимальний код, ніж стерпним операційним системам, однак вони надають можливість максимально використовувати ручну оптимізацію коду

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

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

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

Хороший приклад – планртровщік Велика частина планувальника-написана незалежним від апаратної платформи чином на мові С Реалізація знаходиться у файлі kernel / schedс Деякі з функцій планувальника, такі як перемикання стану процесора або перемикання адресного простору, дуже сильно залежать від апаратної платформи Отже, функція context_switc h (), яка перемикає виконання від одного процесу до іншого і написана на мові С, викликає функції switch_t o () і Kwitch_ram () для перемикання стану процесора і перемикання адресного простору відповідно

Код функцій switch_t o () і switch_m m () виконаний окремо для кожної апаратної платформи, яку підтримує операційна система Linux Коли операційна система Linux портується на нову апаратну платформу, то для нової апаратної платформи просто необхідно реалізувати ці функції

Файли, які відносяться до певної апаратній платформі, знаходяться в каталозі arch / <апаратно я платформа> / і include/asm- /, де <апппаратна я платформа> – Це коротке імя, яке представляє апаратну платформу, підтримувану ядром Linux Наприклад, апаратній платформі Intel х8б присвоєно імя i386 Для цього типу машин файли знаходяться в каталогах arch/i38 6 і include/asm-i386 Ядра серії 26 підтримують такі апаратні платформи: alpha, arm, cris, h8300, i38, ia64, m68k, m68knommu, mips, mips64, parisc, ppc, ppc64, s390, sh, spare, sparc64, um, v850 і х8б-Б4 Більш повний опис наведено в табл 191

Джерело: Лав, Роберт Розробка ядра 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>

*

*