Содержание


Linux на POWER: Перенос дистрибутива и вопросы двоичной совместимости

Какая связь существует между двоичной совместимостью и различными операционными средами, работающими на Linux на POWER

Comments

Сегодня есть много различных дистрибутивов Linux. Хотя IBM поддерживает двух поставщиков для решений Linux на POWER, Red Hat и SUSE LINUX, другие дистрибутивы, Gentoo, Debian и Ubuntu, тоже приобретают популярность для Linux на POWER. Разработчики приложений обычно заинтересованы в том, чтобы их приложения работали на нескольких дистрибутивах и на различных версиях данного дистрибутива. Эти цели могут быть достигнуты за счет понимания проблем, связанных с двоичной совместимостью. В этой статье дается определение двоичной совместимости, обсуждаются вопросы сохранения совместимости, и рассматривается перенос между различными версиями Red Hat Enterprise Linux, версии 4 и 5, и SUSE LINUX Enterprise Server, версии 9 и 10. В ней также рассматриваются методы, которые могут обеспечить совместимость при работе приложения в нескольких дистрибутивах.

В таблице 1 приводятся уровни программного обеспечения и поддерживаемые возможности, которые есть в RHEL4, RHEL5, SLES9 и SLES10 и которые подробно рассматриваются в этой статье:

Таблица 1. Поддерживаемые возможности и версии в дистрибутивах RHEL и SLES
SLES8 SP4RHEL3 U4SLES9 SP3RHEL4 U8SLES10 SP2RHEL5 U3
ядро2.4.212.4.212.6.52.6.92.6.162.6.18
glibc2.2.52.3.22.3.32.3.42.42.5
SMT Нет Нет Да Да Да Да
NPTL Нет Нет Да Да Да Да
NUMA Нет Нет Да Да Да Да
JDK IBM 1.3.1IBM 1.4.2¹IBM 1.4.2IBM 1.4.2IBM 1.4.2, 5.0IBM 1.4.2, 5.0
Apache 1.3.262.0.462.0.492.0.522.2.02.2.3
GCC 3.23.2.33.3.33.4.64.1.24.1.2

¹¹Можно загрузить IBM Developer Kit for Linux, Java™ Technology Edition, с сайта IBM. (См. ссылку в разделе Ресурсы.)

С помощью диаграммы на рисунке 1 можно определить, обладает ли приложение двоичной совместимостью с RHEL или SLES.

Рисунок 1. Определение двоичной совместимости приложения
Определение двоичной совместимости приложения
Определение двоичной совместимости приложения

Обзор двоичной совместимости

Двоичная совместимость Linux на POWER делается возможной благодаря соответствию двоичному интерфейсу приложений (Application Binary Interface, ABI). ABI — это интерфейс, с помощью которого скомпилированный двоичный файл получает доступ к операционной системе и ее службам. Когда несколько операционных сред поддерживают один и тот же ABI, то один и тот же двоичный файл может работать на этих средах. Дополнительную информацию о 64-разрядном дополнении к ABI для формата ELF для PowerPC®можно найти в "64-разрядном дополнении к двоичному интерфейсу приложений в формате ELF для PowerPC версия 1.7" (См. ссылку в разделе Ресурсы).

Двоичная совместимость — это способность взять двоичный файл и запустить его на выполнение на нескольких операционных средах данного семейства процессоров. Эти среды могут быть разными версиями одного и того же дистрибутива Linux или они могут быть совершенно разными дистрибутивами. Один пример: работа двоичного файла, который собран и запущен на выполнение на системе с процессором POWER5™, работающей под SLES10, и запуск его на выполнение на системе с процессором POWER6™, также под управлением SLES10. Другой пример: двоичный файл, собранный и работавший в системе с процессором POWER5 под управлением RHEL4, и выполнение того же двоичного файла на системе с процессором POWER6 и SLES10.

Совместимость процессоров

Совместимость процессоров близко связана с двоичной совместимостью для Linux на POWER. В этом разделе рассматривается совместимость между различными 64-разрядными процессорами POWER и совместимость между 32-разрядными процессорами PowerPC и 64-разрядными процессорами POWER.

Совместимость процессоров POWER

В последнем примере в разделе "Обзор двоичной совместимости" говорилось о запуске двоичного файла на двух различных типах процессоров: процессор POWER5 и процессор POWER6. Архитектура POWER6 содержит усовершенствования по отношению к архитектуре POWER5, в то же время сохраняя двоичную совместимость между ними, что позволяет запускать одно и то же приложение на обеих платформах.

Совместимость процессоров PowerPC и POWER

Существует двоичная совместимость между 32-разрядными приложениями, работающими в «родной» 32-разрядной среде PowerPC, и 64-разрядной средой POWER. Возможно также выполнение 32-разрядных двоичных файлов в «родных» средах Linux PowerPC, если они были созданы на 64-разрядной системе Linux на POWER. Эта совместимость возможна, потому что:

  • 64-разрядная архитектура Power поддерживает 32-разрядную архитектуру PowerPC целиком.
  • 64-разрядное ядро Linux обрабатывает 32-разрядные системные вызовы.
  • 32-разрядные среды выполнения содержат необходимые 32-разрядные библиотеки.
  • 64-разрядные среды выполнения содержат необходимые 32-разрядные и 64-разрядные библиотеки.

В зависимости от платформы разработки существует несколько различных способов создания 32-разрядных и 64-разрядных двоичных файлов Linux:

  • «Родной» C-компилятор из набора GNU Compiler Collection (GCC) на 32-разрядной платформе PowerPC, например, Apple Powerbook, работающий под Linux, может создавать 32-разрядные двоичные файлы, которые могут выполняться на своей «родной» 32-разрядной платформе или на 64-разрядных платформах Linux на POWER, содержащих подходящие 32-разрядные библиотеки пространства пользователя.
  • C-компиляторы IBM XL C/C++ версии 8.0 и GCC для 64-разрядного Linux на POWER могут создавать 32-разрядные и 64-разрядные двоичные выполняемые файлы, которые могут выполняться либо в 32-разрядных, либо в 64-разрядных средах выполнения.
  • Имеются кросс-компиляторы для 32-разрядных Linux-систем на PowerPC и для 64-разрядных систем с Linux на POWER. Эти кросс-компиляторы могут создавать как 32-разрядные, так и 64-разрядные двоичные файлы. Независимо от того, где был собран двоичный файл, 32-разрядный двоичный файл может работать как на 32-разрядной Linux-платформе, так и на 64-разрядной платформе, тогда как 64-разрядный двоичный файл может работать только на 64-разрядной системе с Linux на POWER. Crosstool является примером кросс-компилятора (см. ссылку для загрузки в разделе Ресурсы).

В таблице 2 показывается, как создавать 32-разрядные и 64-разрядные двоичные файлы для Linux для различных платформ разработки:

Таблица 2. Создание 32-разрядных и 64-разрядных двоичных файлов для Linux
Платформа разработкиКомпиляторСозданный двоичный файл для Linux
32-разрядный Linux на PowerPCРодной C-компилятор GCC32-разрядный
64-разрядный Linux на POWERРодной компилятор XL C/C++ или C из GCC32- или 64-разрядный
32-разрядный Linux на PowerPC или
64-разрядный Linux на POWER
Кросс-компилятор (например, crosstool)32- или 64-разрядный

Хотя продемонстрирована совместимость между 32-разрядными и 64-разрядными средами, это не означает, что дистрибутивы официально поддерживают этот тип совместимости. Red Hat поддерживает прямую и обратную совместимость 32- и 64-разрядных систем между RHEL3 и RHEL4, в то время как SLES8 поддерживает только прямую совместимость 32-разрядных приложений при переходе с SLES8 на SLES9.

В таблице 3 показывается прямая и обратная совместимость 32- и 64-разрядных приложений на различных версиях RHEL и SLES:

Таблица 3. 32-разрядная и 64-разрядная совместимость в дистрибутивах RHEL и SLES
Дистрибутив32 разряда64 разряда
RHEL3 > RHEL4Прямая совместимостьПрямая совместимость
RHEL4 < RHEL3Обратная совместимостьОбратная совместимость
SLES9 > SLES8Прямая совместимость Нет
SLES8 < SLES9 Нет Нет

Оптимизация производительности

Ядро 2.6 и архитектура POWER6 содержат особенности, которые могут увеличить производительность приложения. Этот прирост производительности происходит благодаря различным библиотекам, особенностям процессоров и обновленным компиляторам. Некоторые из составляющих прироста производительности действуют сразу без каких-либо изменений приложения, а для других требуется перекомпиляция исходного текста. Имейте в виду, что перекомпиляция с целью получения выигрыша в производительности может нарушить двоичную совместимость в некоторых средах. В этом разделе приводятся примеры новых возможностей ядра 2.6 и архитектуры POWER6, которые могут увеличить производительность приложения.

NUMA

Неоднородная архитектура памяти (Non-uniform Memory Access, NUMA) была представлена в ядре 2.6 для Linux на POWER, и эта особенность подверглась дальнейшей оптимизации в последних выпусках RHEL5 и SLES10. NUMA справляется с проблемой, которая возникает, когда определенным процессорам в системе, в зависимости от того, где они находятся на шине, требуется больше времени, чем другим процессорам, чтобы получить доступ к определенным областям памяти. NUMA уменьшает состязание за шину разделяемой системной памяти за счет увеличения числа шин памяти и уменьшения числа процессоров на каждой шине. Хотя в системе с небольшим числом процессоров это не играет существенной роли, может быть выигрыш в производительности, когда в системе большое число процессоров.

В случае ядра Linux 2.6.15, оптимизация за счет NUMA повышает производительность для рабочих нагрузок, распределенных в больших системах (более 4-8 процессорных ядер), если указать, что доступ к памяти могут получать лишь локальные процессоры. Если процессор ищет данные, которые находятся в памяти на соседних модулях, ядро 2.6.16 может захватить эту информацию и перенести ее в в локальную память (которая работает намного быстрее), а затем делать ту операцию, которая требовалась с этой информацией, без необходимости перезапуска этой операции.

Архитектуры POWER5 и POWER6 масштабируются до 64 процессоров, поэтому большинство приложений выиграют от поддержки NUMA на уровне ядра 2.6. Приложения, для которых требуется дополнительный прирост производительности, могут использовать NUMA API в пространстве пользователя. RHEL4 поставляется с API NUMA в пространстве пользователя, а дополнительная информация о том, как пользоваться этими API есть на домашней странице NUMA Group (ссылку см. в разделе Ресурсы).

В ядре 2.6.16 были сделаны некоторые изменения в способе размещения этой разделяемой памяти. Если процессор ищет данные, которые находятся в памяти на соседних модулях, ядро Linux 2.6.16 может захватить эту информацию и перенести ее в локальную память (которая работает намного быстрее), а затем делать ту операцию, которая требовалась с этой информацией, без необходимости перезапуска этой операции.

Совершенствование компиляторов

Можно решить сделать перекомпиляцию, чтобы воспользоваться приростом производительности за счет использования новых возможностей последних компиляторов для Linux на POWER. Есть высокопроизводительный компилятор IBM XL C/C++ версия 8 для базовых уровней RHEL4, SLES9 и SLES10. Есть IBM XL C/C++ версия 9 для RHEL5 и последующих обновлений, а также для SLES10 SP1 и SP2. Версия 9 добавляет выигрыш в производительности для систем на основе процессоров POWER6.

Параметры -qarch и -qtune используются для оптимизации производительности для соответствующих архитектур. Например, для оптимизации для POWER6 используйте -qarch=pwr6 и -qtune=pwr6. А еще добавлен параметр -qtune=balanced. Этот параметр, если его использовать совместно с -qarch=pwr5 (или pwr5x), создает двоичный файл, который работает на системах и с POWER5, и с POWER6, но с улучшениями работы планировщика, которые должны повысить производительность POWER6. Версия 9 также содержит поддержку для расширений команд AltiVec Vector Multimedia Extensions (VMX) при использовании параметра -qaltivec, эти расширения первоначально были предложены на процессоре IBM PowerPC 970, а теперь включены в семейство процессоров POWER6.

Комплект компиляторов GNU содержит компиляторы для множества языков программирования. Были сделаны усовершенствования при переходе от версии 3.3 к 4.1, в том числе специфическая для процессора POWER6 оптимизация для его C-компилятора, gcc. Теперь поддерживаются флаги -mcpu=power6 и -mtune=power6, и их действие проявляется в том, что параметры использования регистров и планирования выполнения команд нацелены на архитектуру POWER6. Есть также векторные расширения VMX для процессоров IBM PowerPC 970 и IBM POWER6, которые могут повысить производительность векторизованного кода. Хотя эти оптимизации повышают производительность на соответствующих архитектурах, они могут нарушить двоичную совместимость приложений, работающих на других платформах.

Дополнительную информацию по использованию компилятора XL C/C++ для Linux на POWER можно найти в статье на developerWorks "Как использовать IBM XL C/C++ Advanced Edition V8.0 для Linux на POWER: Руководство для пользователей GCC."

SMT

Параллельная многопоточность (Simultaneous Multi-threading, SMT) обеспечивает еще одну возможность получить прибавку производительности при переходе на ядро Linux 2.6. SMT поддерживается на процессоре POWER6 и значительно увеличивает производительность приложений, в значительной степени использующих многопоточность. Микросхема POWER6 имеет два аппаратных потока команд, которые оба способны выдать несколько команд на цикл, что приводит к приросту производительности. Однако SMT может вызвать снижение производительности в некоторых приложениях, которые не используют активно потоки. SMT может быть отключен передачей параметра smt-enabled=off ядру Linux при загрузке.

Другие усовершенствования ядра 2.6

С ядром 2.6 в RHEL4 и SLES были внесены следующие особенности, повышающие производительность, и они продолжают совершенствоваться в версиях RHEL5 и SLES10:

  • Масштабируемость и возможности 64 SMP-процессоров POWER6.
  • Поддержка больших страниц для приложений с интенсивным использованием памяти, что позволяет использовать страницы размером 16MB, в то же время по-прежнему предоставляя традиционный размер страниц 4KB.
  • Введение размеров страниц 64KB в Red Hat Enterprise Linux 5.
  • Усовершенствования в подсистеме виртуальной памяти, в том числе алгоритм обратного отображения, который дает улучшения в системах с ограниченной памятью.
  • Улучшения блочного ввода-вывода и асинхронного ввода-вывода.

Переход с RHEL4 на RHEL5

Red Hat поддерживает стабильный ABI между RHEL4 и RHEL5, что позволяет осуществлять плавный перенос приложений между версиями. Однако для гарантии двоичной совместимости Red Hat рекомендует компоновать интерфейсы приложений с теми основными библиотеками, которые они указали. Это в том числе:

  • libc, libgcc, libstdc++, libdl, libm, libutil, libcrypt, libz, libpthread, libncurses
  • libX11, libXext, libXt, libICE, libSM, libGL
  • libgtk, libgdk, libgdk_pixmap, libpango, libatk, libglib, libgmodule, libgthread, libgnomeprint, libgnomeprintui, libgconf, libglade

Основные библиотеки и другие вопросы совместимости подробно описываются в статье "Совместимость приложений Red Hat Enterprise Linux 4" (см. ссылку в разделе Ресурсы). Хотя в этом документе речь идет о совместимости в RHEL4, те же самые концепции и идеи могут применяться к совместимости приложений в RHEL5. Приложение, в котором используются библиотеки, не входящие в основной набор, все же может сохранять совместимость, но следует произвести дополнительное регрессивное тестирование. Другие случаи, когда приложения не могут сохранять двоичную совместимость, это, например, такие, когда приложения статически связываются с любой библиотекой, зависят от интерфейсов уровня ядра или конфликтуют со стандартами POSIX или определениями 64-разрядного ABI POWER.

Не только ABI стабильно между RHEL4 и RHEL5, но и многие функции ядра 2.6, которые есть в RHEL5, были обратно перенесены в RHEL4. Это дает возможность приложениям RHEL4, уже использующим преимущества таких особенностей, как Simultaneous Multi-threading (SMT) и Native Posix Thread Library (NPTL), получать прирост производительности за счет использования возможностей, включенных в RHEL5, без необходимости перекомпиляции исходного текста. Эти приложения также получат прирост производительности от усовершенствований, идущих с ядром 2.6, как уже описывалось ранее в этой статье.

Есть, однако, две области, в которых перекомпиляция на RHEL5 может увеличить производительность приложения:

  • Для систем с большим числом процессоров может оказаться полезным перекомпиляция с использованием пользовательских API для NUMA в RHEL5, если это уже не было сделано на RHEL4. Хотя приложения в общем случае получат прирост производительности от поддержки NUMA на уровне ядра, дополнительное увеличение производительности может быть достигнуто путем сборки с использованием этих API уровня пользователя. Приложения, которые интенсивно используют процессор и часто обращаются к памяти, получат наибольший выигрыш, потому что NUMA уменьшает время, которое требуется процессору для доступа к области памяти.
  • Другие приложения тоже могут получить прирост производительности в результате перекомпиляции с использованием последних компиляторов, имеющихся для RHEL5. Эти компиляторы имеют дополнительные флаги, которые используют преимущества оптимизаций POWER6, о которых ранее говорилось в этой статье.

Необходимо учитывать риск нарушения двоичной совместимости при перекомпиляции приложения для повышения производительности. Хотя в большинстве случаев нет необходимости в дополнительной работе над приложением при переходе с RHEL4 на RHEL5.

Переход с SLES9 на SLES10

Переход с SLES9 на SLES10 тоже должен быть относительно гладким. Хотя в SLES 9 была введена модель потоков NPTL вместо использования более старой модели LinuxThreads, NPTL является единственной поддерживаемой моделью потоков в SLES10, поскольку поддержка LinuxThreads в Glibc считается устаревшей. Проблемы, возникающие вследствие смены модели потоков, описываются в разделе "Поточная модель", в котором рассматриваются проблемы при переходе с одной модели потоков на другую. Поскольку приложения, не использующие потоков и которые используют меньший набор общих библиотек, имеют больше шансов для сохранения двоичной совместимости между версиями SLES, делайте регрессивное тестирование для гарантии качества.

Как и в случае с RHEL, есть ситуации, когда перекомпиляция исходного текста может пойти на пользу приложению, предназначенному для работы на SLES10. Например, приложение может получить прирост производительности за счет использования улучшенных компиляторов, имеющихся для SLES10. SMT — это тоже новая возможность в SLES10, которая даст преимущества приложениям, интенсивно использующим потоки.

В общем случае, большинство приложений, не использующих потоки, будут двоично совместимыми между SLES9 и SLES10. Однако, когда есть большие изменения в библиотеках и версиях ядра, перекомпиляция из исходных текстов является, вероятно, наилучшим выбором для разработчика, старающегося получить оптимальные параметры работы от своего приложения.

Обеспечение совместимости между дистрибутивами

Написание приложения, переносимого между несколькими дистрибутивами Linux, может показаться трудной задачей, но она может быть достигнута, если следовать нескольким простым правилам. В последние версии большинства дистрибутивов обычно входят версии библиотек и ядер одного уровня. В большинстве дистрибутивов используется и аналогичный формат файлов конфигураций и данных.

И Red Hat, и Novell принимают участие в разработке проекта Linux Standard Base, или LSB, проекта в рамках организации Linux Foundation, с целью разработки и продвижения набора открытых стандартов, которые увеличат совместимость между дистрибутивами Linux и позволят приложениям работать на любой совместимой системе, даже в двоичной форме. Кроме того, LSB поможет скоординировать усилия по привлечению поставщиков программного обеспечения для переноса и создания продуктов для операционной системы Linux. Ключевым компонентом LSB является письменная спецификация двоичного интерфейса, которая указывает разработчикам приложений Linux стандартные способы сборки и конфигурирования их приложений. А именно, в этой спецификации перечисляются:

  • Рекомендации по упаковыванию и установке
  • Разделяемые библиотеки общего назначения и их выбор
  • Файлы конфигурации
  • Расположение файлов
  • Системные команды
  • Двоичные прикладные интерфейсы (Application Binary Interface, ABI) для системных интерфейсов (как на уровне приложений, так и платформ)

В следующем разделе рассматриваются некоторые спецификации LSB и даются рекомендации, следуя которым нужно писать приложения, которые будут переносимыми между различными дистрибутивами.

У многих дистрибутивов Linux имеется одинаковый ABI и общепринятый набор основных библиотек. Однако в каждом дистрибутиве определение основного набора библиотек слегка варьируется, что означает, что всегда необходимо регрессивное тестирование, чтобы утверждать, что приложение поддерживается в данном дистрибутиве.

Например, если внимательнее взглянуть на библиотеки glibc, которые содержатся в дистрибутивах RHEL и SLES, можно увидеть, что в RHEL4 находится версия 2.3.4, а в SLES9 — 2.3.3. Отличия в дополнительном номере версии обычно относятся к исправлениям ошибок без добавления новых возможностей. RHEL4, RHEL5, SLES9 и SLES10 также имеют схожие потоковые модели, поэтому любое приложение, скомпонованное с общими библиотеками, должно запускаться на всех этих трех операционных средах. Общие библиотеки можно найти и в других дистрибутивах, например, Gentoo и Debian.

В стандарте File Hierarchy Standard (FHS) определяется, как должны располагаться файлы и каталоги на UNIX®-подобных системах. FHS следует использовать, если приложение рассчитано на использование других сторонних файлов данных и конфигурации. Главная цель FHS состоит в том, чтобы предоставить приложениям общеупотребительное расположение для поиска стандартных конфигурационных файлов. Дополнительную информацию по FHS можно найти на домашней странице проекта Filesystem Hierarchy Standard. (См. ссылку в разделе Ресурсы.)

Хотя в общем случае нельзя гарантировать двоичную совместимость между всеми дистрибутивами Linux, можно, тем не менее, заявлять о поддержке для большинства современных дистрибутивов, если следовать этим принципам.

Двоичная совместимость

Хотя двоичная совместимость была определена в связи с ABI и семействами процессоров, есть и другие вопросы совместимости, которые тоже должны рассматриваться, когда нужно решить, будет ли приложение работать в нескольких средах. Это, например, модели потоков, низкоуровневые зависимости ядра, промежуточное ПО и основные библиотеки. В этом разделе рассматриваются эти вопросы и описывается, как Linux на POWER справляется с ними.

Потоковая модель

Модель для обслуживания потоков в Linux изменилась с выпуском glibc 2.3 и переходом ядра Linux с версии 2.4 на версию 2.6. Традиционная модель LinuxThreads, использовавшаяся в glibc 2.2 и ядре 2.4, была замещена библиотекой Native Posix Thread Library (NPTL). NPTL была переписана с нуля и обеспечивает значительный прирост производительности для приложений с интенсивным использованием потоков. Подробные сведения по спецификациям NPTL можно найти в статье Red Hat "Библиотека Native POSIX Thread Library для Linux" (см. ссылку в разделе Ресурсы for a link).

SLES8 построен на основе ядра 2.4 и содержит модель LinuxThreads, что представляет проблему, если попытаться запустить потоковое приложение на SLES9, в которой используется потоковая модель NPTL. Для этой проблемы есть два решения:

  • Внести небольшие изменения в исходный текст и перекомпилировать с использованием библиотек на основе NPTL, получив преимущества от прироста производительности за счет NPTL. Дополнительную информацию о переходе с модели LinuxThreads на модель на основе NPTL можно найти в статье на LinuxDevices.com "Перенос приложений на ядро 2.6 и NPTL" (см. ссылку в разделе Ресурсы).
  • Установить переменную среды LD_ASSUME_KERNEL, которая обеспечивает обратную совместимость с моделью LinuxThreads в SLES9. Если установить эту переменную, то компоновщик полагает, что работает ядро 2.4 со старой моделью LinuxThreads. Разработчик Red Hat Ульрих Дреппер (Ulrich Drepper) подробно рассказал про переменную LD_ASSUME_KERNEL (см. ссылку в разделе Ресурсы). Однако, из-за изменений в glibc в SLES10, приложения, которые зависят от семантики более старой модели LinuxThreads, не будут работать, потому что более старая модель LinuxThreads замещена более новой моделью NPTL в SLES 10. Это также означает, что переменной среды LD_ASSUME_KERNEL можно присвоить значение лишь больше, чем "2.6.4." Лучше всего попробовать более новую NPTL, которая установлена по умолчанию в SLES 9.

Низкоуровневые зависимости ядра

Низкоуровневые зависимости ядра — это еще одна область, которую нужно принимать во внимание, запуская приложения в различных операционных средах. Перенесение информации из файловой системы /proc в файловую систему sysfs является примером того, как приложение может быть не совместимо, даже если оно написано с использованием жестко заданных параметров в исходном тексте для одной из этих файловых систем. Первоначально файловая система /proc была размещаемой в памяти файловой системой, которая давала возможность осуществлять доступ из пространства пользователя к структурам данных ядра, в которых содержались такие сведения, как информация о системе и о состоянии устройств. Эта информация переносится из файловой системы /proc в файловую систему sysfs. Файловая система /proc все еще существует, но она будет содержать лишь информацию о процессах.

Хранение списка устройств Universal Serial Bus (USB) является примером перемещения системной информации из файловой системы /proc в файловую систему sysfs. Приложение, первоначально написанное на системе, базирующейся на ядре 2.4, находило этот список устройств в /proc/bus/usb/devices. С переходом на ядро 2.6 и файловую систему sysfs эта информация была перенесена в /sys/bus/usb/devices. Это перемещение информации может привести к тому, что приложение будет неправильно работать. Хотя эта ситуация и не является типичной, вам следует знать о таких потенциальных проблемах на уровне ядра.

Промежуточное ПО и совместимость приложений

Многие приложения сегодня не являются самостоятельными, а зависят от промежуточных приложений. Промежуточное программное обеспечение — это такое программное приложение, которое находится между двумя приложениями или между приложением и операционной системой. Примерами промежуточного ПО являются IBM DB2® Universal Database for Linux, Java™ Development Kit (JDK) и приложения IBM WebSphere®. Разработчик может определить версию промежуточного ПО, на котором поддерживается его приложение, но поставщик промежуточного ПО решает, на каких дистрибутивах Linux будет работать их продукт. Список промежуточного ПО IBM для Linux имеется на сайте программного обеспечения IBM для Linux (см. ссылку в разделе Ресурсы). Кроме промежуточного ПО, приложение может зависеть и от других приложений, поставляемых с дистрибутивом. Примерами являются веб-сервер Apache, системы баз данных, например, mysql и postgresql, и интерпретируемые языки программирования, например, perl и python.

В качеcтве примера давайте ближе взглянем на то, как использование Java может влиять на разработчика приложений. Пакет промежуточного ПО Java привлекает большое внимание, поскольку из-за платформенной независимости существует большое число Java-приложений. Существуют не только различные версии и поставщики пакетов JDK, но они еще бывают в виде 32-разрядных и 64-разрядных версий для Linux на POWER. RHEL4 поставляется с 32-разрядным SDK для Linux V1.4.2 от IBM. RHEL5 поставляется и с 32-разрядным SDK для Linux V1.4.2 от IBM, и с 32-разрядным SDK для Linux V1.5 от IBM. SLES9 SP3 поставляется с 32-разрядным SDK для Linux V1.4.2 от IBM, а SLES10 SP2 - с 32-разрядной версией IBM SDK V1.4.2 и 32-разрядным и 64-разрядным SDK для Linux V1.5 от IBM. Разработчик приложений должен знать об этих различиях, если приложение зависит от возможностей, имеющихся только в версии 5.0.

Еще один пример: веб-сервер Apache является приложением, которое не считается промежуточным ПО, но многие приложения зависят от него. Версия 2.2 является новейшей версией Apache и поставляется с RHEL5 и SLES10, а RHEL4 и SLES9 идут с версией 2.0. Если в приложении имеются новые возможности, которые есть только в Apache 2.2, то приложение может быть не совместимым с версией 2.0 Apache, поставляемой с RHEL4 и SLES9.

Основные библиотеки

Большие изменения в основных библиотеках тоже могут представлять проблему при попытке добиться двоичной совместимости. Обратная совместимость поддерживается в промежутках между большими изменениями в библиотеках. Это дает возможность приложениям, скомпилированным с использованием старой версии данной библиотеки, работать с новой версией этой же библиотеки. Приложение, скомпилированное с использованием последней версии данной библиотеки, не будет работать в среде со старой версией этой библиотеки, если между версиями сделаны большие изменения.

Например, двоичный файл, собранный на системе с SLES9 с glibc 2.3.3, будет работать и на системе с SLES10 с glibc версии 2.4, поскольку версия 2.4 обратно совместима. Однако, тот же самый исходный файл, собранный на системе с SLES10, не будет работать на системе с SLES9 из-за более старой glibc. Обычно это представляет проблему только в случае, когда приложение разрабатывается на текущем дистрибутиве, и планируется поддерживать это приложение на старой версии дистрибутива, который не предоставляет старых совместимых библиотек.

Список благодарностей

Я хотел бы выразить свою признательность Линде Киннунен (Linda Kinnunen) за ее полезные обзоры, а также Бренту Боду (Brent Baude) и Мэтту Дейвису (Matt Davis) за их техническую помощь и обзоры.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=604333
ArticleTitle=Linux на POWER: Перенос дистрибутива и вопросы двоичной совместимости
publish-date=12212010