Проблеми сумісності Linux-систем

1. Проблеми сумісності додатків
2. структура Linux
3. конфігурації
4. дистрибутиви
5. проект OLVER

26.02.2007 Олексій Гриневич, Денис Марковцев, Володимир Рубанов

Для вирішення інфраструктурної проблеми слабкої сумісності різних версій Unix в 1985 році в рамках IEEE було розпочато роботу над стандартом, що забезпечує переносимість програмного забезпечення. У 1990 році побачив світ стандарт IEEE 1003, який також отримав назву POSIX [ 1 ], Який регламентував програмні інтерфейси (API) і перелік команд Unix-клонів. Однак для гравців ринку Unix уніфікація породила складні політичні проблеми: будь-яке рішення, будь-який вибір між альтернативними варіантами для досягнення згоди веде до того, що «більш стандартним» визнається рішення одного виробника в порівнянні з рішенням іншого. В результаті стандарт рясніє багатозначними твердженнями типу «в даному випадку можливий один з двох альтернативних варіантів поведінки» і білими плямами на зразок «стандарт не регламентує поведінку функції в цьому випадку». Зрештою, фрагментація стала однією з основних причин поразки світу Unix. Гравці цього ринку конкурували не тільки з іншими типами операційних систем, але і один з одним, вводячи приватні розширення і закриті інтерфейси, обмежуючи коло можливих додатків будь-яким одним клоном.

Розгромна замовна стаття на початку 90-х років ОС Linux, що увібрала в себе код, створений в рамках руху GNU, і ввібрала основні ідеї Unix, завдяки відкритості та незалежності стала універсальним компромісом. Її код реалізовувався з нуля, не спираючись на будь-яку реалізацію, а тільки на текст стандарту POSIX. В результаті система вийшла спочатку POSIX-сумісної, а незалежність дозволила об'єднати зусилля різних гравців ринку Unix в боротьбі за «повернення» упущеного сегмента операційних систем для ПК. Однак проблема фрагментації залишилася актуальною і для Linux: наявність конкуруючих між собою дистрибутивів викликає побоювання у вірогідному повторенні долі Unix.

На перший погляд, сама небезпека фрагментації виглядає досить примарною - фактично є загальний код, більшість дистрибутивів працюють на основі одного і того ж ядра, одних і тих же бібліотек, що багато в чому визначає сумісність. Здавалося б, і додатки повинні зберігати працездатність і сумісність між різними версіями Linux. Але це не отримує підтвердження на практиці. Поряд з фрагментацією ринку дистрибутивів Linux за підходами і додаткової функціональності, спостерігаються істотні перекоси в підтримці різними клонами навіть поширених і стандартних додатків - в різних дистрибутивах використовуються різні версії ядра і системних бібліотек (в першу чергу, glibc). Це веде до того, що склад і поведінку системних інтерфейсів, що надаються системою додатків, змінюються від дистрибутива до дистрибутива. Для того щоб не повторити сумний досвід клонів Unix, в 1998 році в рамках спеціально створеної організації Free Standards Group (зараз Linux Foundation [2]) почалася робота над стандартом LSB (Linux Standard Base - «базове сімейство стандартів Linux»). Завдяки зусиллям з боку організацій X / Open, IEEE і ISO, які відкрили стандарт POSIX і частина тестів для вільного доступу, був закладений фундамент в справу стандартизації Linux.

Але що саме і навіщо потрібно стандартизувати? Невже єдиний відкритий код сам по собі не є єдиним і відкритим стандартом?

Проблеми сумісності додатків

Як проявляються відмінності між збірками Linux на практиці і наскільки серйозна проблема? Наведемо приклад. Основу комерційних пропозицій корпорації IBM складають п'ять лінійок програмних продуктів: DB2, Websphere, Rational, Tivoli і Lotus. Практика показує, що підтримка всіх п'яти лінійок для одного дистрибутива Linux обходиться щорічно в мільйони доларів, які йдуть на розробників і тестувальників, відповідальних за підтримку додатків під конкретний дистрибутив Linux. Отже, підтримуються ті дистрибутиви, для яких прибуток від продажу продуктів перевищує ці мільйони; фактично це тільки дистрибутиви SuSE і Red Hat. Так виникає ситуація невідповідності - то, що працює на одних дистрибутивах, що не запускається на інших.

Зовсім інша ситуація спостерігається для Sun Solaris. Перш за все, в Sun Microsystems гарантують, що програма, скомпільована для Solaris 2.6, буде працювати без перекомпіляції і під версією 10. Розробники Sun докладають величезних зусиль для цього; при кожній зміні коду проганяється набір більш ніж з 2400 додатків різного призначення і складу. Більш того, якщо хтось виявляє, що додаток перестало працювати через несумісність між версіями Solaris, то в Sun беруть на себе відповідальність і витрати на виправлення цієї невідповідності. У випадку з ОС Linux дана робота довгий час не велася, додатки та дистрибутиви жили своїм власним відособленим життям. Найсумнішим при цьому є відсутність універсального способу написання програми таким чином, щоб гарантовано забезпечити переносимість. На вирішення цієї проблеми і спрямовані зусилля консорціуму Linux Foundation, що представляє інтереси основних гравців Linux-ринку.

структура Linux

Нерідко під Linux розуміють лише його ядро, але є безліч речей, якими ядро ​​займатися не повинно. Робота з документами, посилка пошти, обробка XML, отрисовка вікон - для всього цього є спеціальні бібліотеки, що входять до складу практично всіх дистрибутивів. Ці бібліотеки, так чи інакше, призводять до виклику ядра, але проблеми і помилки можуть виникати не тільки в ядрі, але і в самих бібліотеках.

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

«Узагальнена» модель системи на базі Linux представлена ​​на Мал. 1.

Мал. 1. Модель системи на базі ОС Linux

Кожна конкретна Linux-система створюється для роботи одного або декількох додатків, однак коду самого додатка недостатньо, щоб витягти необхідний користувачам сервіс з апаратури - більшість додатків використовує в своїй роботі звернення до функцій бібліотек. Стандарт LSB Core 3.1 визначає наступні системні бібліотеки: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. В сучасних Linux-системах інтерфейси цих системних бібліотек реалізуються бібліотеками glibc, Linux-PAM, zlib і ncurses, які насправді реалізують більше інтерфейсів, ніж визначено в LSB Core.

За ступенем взаємодії з ядром Linux функції системних бібліотек можна класифікувати так:

• реалізація функції повністю міститься в бібліотеці, і ядро ​​не використовується (наприклад, strcpy, tsearch);
• в бібліотеці реалізується тривіальна «обгортка» (wrapper) для виклику відповідного інтерфейсу ядра (наприклад, read, write);
• реалізація функції містить як виклики системних інтерфейсів ядра (причому можливо кількох різних), так і частина коду в самій бібліотеці (наприклад, pthread_create, pthread_cancel).

Саме ядро ​​Linux містить багато експортованих точок входу, однак переважна більшість з них є внутрішнім інтерфейсом для використання модулями і підсистемами самого ядра. Зовнішній інтерфейс містить близько 250 функцій (версія 2.6). З них, наприклад, у своїй реалізації бібліотека glibc 2.3.5 використовує 137.

конфігурації

Під конфігурацією системної частини дистрибутива розуміється комбінація версії ядра (включаючи окремі латки), версій системних бібліотек, параметрів їх складання і архітектури, на якій це все працює. на Мал. 2 наведено приклад конфігурації збірки двох гіпотетичних дистрибутивів, що представляють собою сукупність версій компонентів і латок. Між версіями компонентів додається нова функціональність, а також прибираються морально застарілі інтерфейси і функції. Так, на даній діаграмі легко бачити, що оскільки дистрибутиви 1 і 2 використовують різні версії GCC, сумісність з вихідних кодів між ними частково втрачено - в повному обсязі, що збиралося за допомогою gcc 3.4, може бути зібрано за допомогою gcc 4.0 без доопрацювання.

Мал. 2. Приклад конфігурації збірки дистрибутивів

дистрибутиви

За адресою lwn.net/Distributions/ можна знайти перелік відомих дистрибутивів Linux (на момент написання статті їх було 542), відкритих для широкої публіки. Тут не враховуються версії, зроблені для внутрішнього застосування індивідуальними ентузіастами, а також різними компаніями, відомствами і т.п. Згідно з ліцензією GNU, можна взяти довільний дистрибутив, внести в нього модифікації (як мінімум в компоненти, які підпадають під GNU) і поширювати далі.

Дистрибутиви можна класифікувати по ряду ознак.

• За базовим виробникам. Наприклад, Red Hat, Slackware, SuSE, Debian, Asianux, Mandriva, Gentoo є основні «гілки» Linux-індустрії. Ці дистрибутиви не є спадкоємцями інших (хоча між ними є деякі історичні залежності). Їх можна вважати стратегічними напрямами розвитку в Linux взагалі. Більшість інших дистрибутивів явно належать до однієї зі згаданих гілок, - в основному наслідуючи вихідний код і додатки і додаючи специфічну функціональність.
• За локалізацією. У багатьох країнах є локальний виробник Linux (скажімо, в Росії всім відомі дистрибутиви ASP Linux і ALT Linux).
• По застосуванню. Дистрибутиви для вбудованого застосування в мобільних пристроях; дистрибутиви, що працюють без підтримки файлової системи; полегшені версії для використання в КПК; переносні версії для запуску з обмежених носіїв (Linux на дискеті, Linux на компакт-диску тощо).
• За спеціалізацією. Дистрибутиви для підтримки певної апаратної архітектури (AlphaLinux з підтримкою процесорної архітектури Alpha, ARM Linux з підтримкою ARM і т.п.).

Процедура складання Linux

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

Різноманіття різних входять до Linux компонентів і безліч залежностей між ними може проілюструвати процедура складання ядра. проект Linux From Scratch містить послідовність кроків, необхідних для складання дистрибутива Linux «з нуля». Спрощена послідовність збірки дистрибутива LFS Linux версії 6.0 виглядає так:

1. Binutils-2.15.94.0.2.2 - Pass 1
2. GCC-3.4.3 - Pass 1
3. Linux-Libc-Headers-2.6.11.2
4. Glibc-2.3.4
...
87. Util-linux-2.12q
88. Конфігурація завантаження
89. Linux-2.6.11.12 - Ядро

Збірка ядра здійснюється на самому останньому етапі за допомогою зібраних перед цим бінарних утиліт. Важливо враховувати версії компонента, наведеного в кожному елементі списку. Заміна однієї версії компонента на іншу не завжди тривіальна - збірка системи може перестати працювати через відсутність або зміни будь-якої функції, або ускладнена. Збірка багатьох компонентів вимагає додаткових дій, наприклад, інструкція по збірці flex для даного дистрибутива містить зауваження * :

Flex contains several known bugs. These can be fixed with the following patch:
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch

У процес складання включається збірка коштів компіляції, які також зазнають суттєвих змін в часі. Навіть базові компоненти Linux нерідко виявляються застарілими. Так, версія компілятора gcc 4.0.0 не годиться для збірки ядра 2.6.11 (хоча вони і сучасники) і вимагає використання спеціальної латки для усунення цієї несумісності.

У полоні залежностей

Фрагментація на рівні бібліотек - дуже серйозна проблема сучасного світу Linux. Частий вихід нових версій бібліотек Linux зазвичай вважається хорошим явищем і, дійсно, тільки так можливо швидко застосовувати і апробувати нові ідеї та робити доступними останні досягнення «інженерної думки»: в широкому використанні іноді знаходяться десятки версій однієї і тієї ж бібліотеки. При цьому невід'ємною рисою розробки окремих компонентів ОС Linux є її децентралізований характер. Часто майже одночасно вийшли нові версії різних компонентів свідомо несумісні, а це означає, що абсолютно неможливо забезпечити адекватне тестування різних комбінацій бібліотек на сумісність і гарантувати стабільну роботу системи при всіх можливих комбінаціях. Як наслідок, вся тяжкість проблем лягає на користувача, який зважився встановити програму або бібліотеку, для якої явно не гарантується здатність роботи в оточенні, існуючому на його машині, і така ситуація складається досить часто.

Категорія проблем, пов'язаних з несумісністю версій бібліотек, отримала назву dependency hell ( «пекло залежностей», en.wikipedia.org/wiki/Dependency_hell ). З якими проблемами може зіткнутися користувач, який встановив в свою версію ОС Linux будь-яку нову бібліотеку? У цьому випадку застосування, які працювали з попередньою версією, можуть перестати коректно функціонувати, так як ці програми могли покладатися явно або неявно на певні помилки і побічні ефекти, які були присутні в старій версії. Також цілком реальна зворотна ситуація, коли нова версія просто містить нову помилку. Але справжня проблема виникає тоді, коли в системі повинні працювати кілька різних додатків, які істотно покладаються на різні версії однієї і тієї ж бібліотеки; може так виявитися, що спільна робота цих додатків просто неможлива. Іноді існує можливість мати кілька версій однієї і тієї ж бібліотеки в системі, і це буде цілком безпечним рішенням, однак це зовсім не рекомендується робити в разі бібліотеки glibc.

LSB

Основний еволюційний шлях до досягнення сумісності різних дистрибутивів Linux - стандартизація. Зрілий і всебічно підтримуваний стандарт дозволить знизити витрати на забезпечення переносимості Linux-рішень, що сприятиме зростанню числа додатків для цієї платформи, а значить і популярності Linux в цілому. Сьогодні в якості такого «рятівного» стандарту виступає Linux Standard Base [3].

LSB - основний стандарт, який визначає вимоги сумісності до Linux-систем. Основні відомості з цього стандарту вже публікувалися, наприклад, в роботі [4], в якій, проте, висвітлювалася стара версія стандарту і кілька перебільшувалася роль інтерфейсів ядра. Насправді стандарт LSB НЕ специфицирует інтерфейси ядра, а визначає більш високорівневі прикладні інтерфейси, реалізовані різними бібліотеками. LSB не намагається бути заміною існуючих стандартів, а навпаки, спирається на всі основні стандарти, вже прижилися в Linux. Він фіксує версії і підмножини складових стандартів, щоб забезпечити узгодженість, і доповнює опису тих інтерфейсів, які присутні де-факто в більшості дистрибутивів Linux, але не увійшли в будь-які існуючі стандарти. Основну частину стандарту LSB складають вимоги до системних інтерфейсів, які повинні підтримуватися всіма збірками Linux (свого роду «загальний знаменник» всіх Linux-систем). У цій частині LSB багато в чому посилається на стандарт POSIX.

Основна відмінність LSB в тому, що розробники додатків можуть орієнтуватися на одну платформу, скажімо LSB 3.1, і цього достатньо для забезпечення роботи на всіх сумісних з LSB 3.1 дистрибутивах. Те ж саме діє і для постачальників дистрибутивів: як тільки досягнута відповідність із LSB 3.1, автоматично дистрибутив підтримує всі сумісні з ним програми. Наприклад, IBM в рамках ініціативи Chiphopper надає апаратні рішення під управлінням тільки LSB-сумісних дистрибутивів. Багато в чому завдяки активності великих гравців основні постачальники дистрибутивів вже пройшли сертифікацію по LSB або оголосили про свої наміри сертифікуватися ( www.linux-foundation.org/en/LSB_Distribution_Status ).

Зараз Основний слабкістю стандарту LSB є недолік тестів. Зустрічаються випадки, коли описів в стандарті інтерфейс працює інакше, и тім НЕ менше система успешно проходити сертифікацію. Це пояснюється тім, что тесту на Данії інтерфейс просто немає, або ВІН дуже Слабкий, щоб повноцінно перевіріті працездатність інтерфейсу. Дуже доречно процитувати висловлювання Яна Мердока, творця Debian, а сьогодні директора з технологій Linux Foundation: «Відомо, що інтерфейсний стандарт гарний настільки, наскільки добре тестове покриття, яке перевіряє відповідність цьому стандарту».

В Open Group відкрили для включення в сертифікаційний набір тестів LSB деякі зі своїх тестів для стандарту POSIX. У набір LSB включені вільні тести стандартної бібліотеки GNU C ++ Runtime Library Test Suite, адаптовані тести для libgtk і libxml. Консорціум Linux Foundation розглядає можливість викупу для відкриття і включення в LSB різних платних тестових наборів.

Займаються вирішенням цього завдання і в нашій країні. Так на базі Інституту системного програмування РАН створений Центр верифікації ОС Linux, фундаментальних і прикладних розробок відкритий тестовий набір OLVER, який планується включити в офіційні тести LSB. Між Центром та Linux Foundation укладено угоду про співпрацю, в рамках якого тривають роботи по поліпшенню тестового покриття LSB і йде розробка нової інфраструктури для розвитку цього стандарту.

Висновок

Для того щоб запобігти фрагментацію, вже мала місце щодо ОС Unix, необхідні заходи забезпечення сумісності дистрибутивів - по крайней мере, в рамках деякого підмножини функціональності. Переносимість додатків в рамках цієї підмножини дозволить об'єднати Linux як єдину платформу і помітно знизити вартість розробки і підтримки додатків, що повинно позитивно позначитися на їх кількості і популярності Linux-рішень в цілому.

Сьогодні основний ініціативою щодо забезпечення переносимості є відкритий стандарт LSB, прийнятий провідними виробниками дистрибутивів (Red Hat, SuSe, Mandriva) і додатків (MySQL, RealPlayer, SAP MaxDB). За цим стандартом стоїть потужний консорціум Linux Foundation і такі його активні члени, як компанії IBM, Intel, HP і Oracle, що дозволяє сподіватися на його успішний розвиток і повсюдне впровадження в реальне життя. Таким чином, в особі стандарту LSB закладений надійний фундамент єдиної, нефрагментовані платформи Linux, що забезпечує переносимість додатків як на основі вихідного коду, так і в бінарному вигляді.

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

література

1. IEEE POSIX Certification Authority, standards.ieee.org/regauth/posix .
2. The Linux Foundation, linux-foundation.org .
3. Linux Standard Base, www.linux-foundation.org/en/LSB .
4. Валерій Коржов, Стандартна база Linux. Відкриті системи, 2005, № 5-6.

Олексій Гриневич, Денис Марковцев - провідні розробники, Володимир Рубанов ( [email protected] ) - менеджер по проектам, ІСП РАН (Москва).

проект OLVER

Проект Open Linux VERification (OLVER) було розпочато в 2005 році центром верифікації ОС Linux за підтримки Федерального агентства з науки та інновацій РФ. Головні цілі проекту:

• аналіз стандарту Linux Standard Base (LSB) Core 3.1 (ISO / IEC 23360-1) з метою виявлення атомарних вимог до поведінки основних системних бібліотек Linux (під атомарним вимогою мається на увазі витяг з тексту стандарту, що відображає просту вимогу, яке можна перевірити);
• виявлення неточностей і помилок в тексті стандарту LSB і пов'язаних з ним стандартів і повідомлення про них оригінальним розробникам для внесення змін в майбутні версії;
• розробка формальних специфікацій на мові SeC (специфікаційні розширення мови програмування С), які будуть відображати вимоги стандарту LSB Core 3.1 для 1530 інтерфейсних функцій Linux;
• розробка відкритих тестових наборів для функціонального тестування різних Linux-систем на відповідність вимогам стандарту LSB Core 3.1 (перевіряється поведінка системних інтерфейсів прикладного програмування Linux).

Тестовий набір заснований на автоматичній генерації тестів з формальних специфікацій вимог і відповідних тестових сценаріїв із застосуванням технології UniTESK.

До кінця 2006 року основна фаза проекту була завершена; всі результати проекту опубліковані на сайті Центру. Зараз проект знаходиться в стадії підтримки і розширення спектра цільових платформ (комбінації апаратної архітектури з конкретним дистрибутивом).

* Flex містить кілька відомих помилок. Вони можуть бути виправлені за допомогою наступної латки ... - англ.