Mr. P.S.
25.07.2007, 13:28
Прошу модераторов удалить следующие сообщения в соседнем топике: #6 (http://forum.antichat.ru/showpost.php?p=419970&postcount=6), #7 (http://forum.antichat.ru/showpost.php?p=419972&postcount=7), #8 (http://forum.antichat.ru/showpost.php?p=419973&postcount=8), #10 (http://forum.antichat.ru/showpost.php?p=420230&postcount=10). Спасибо.
Linux используется в лучшем случае в десятки раз реже, нежели Windows, внимания к ней привлечено меньше, отчего и уязвимости обнаруживаются сравнительно реже. Однако эта осторожная точка зрения не учитывает одного важного нюанса: принципиальной разницы в подходах к разработке проприетарного и свободного софта. В случае с программным обеспечением с закрытым кодом разработчикам чаще всего платят за их труд. В случае с open source-продуктами девелоперы трудятся либо из чистого интереса, либо получая вознаграждение не напрямую; кроме того, они неизбежно взаимодействуют с массой разработчиков разных интересов и квалификации - в силу открытости исходных текстов. Так почему бы свободному программному обеспечению и в самом деле не содержать меньше ошибок? Эта сладкая для приверженцев идеи открытого кода теория безусловно имеет право на жизнь, но что самое интересное - подтверждается реальными фактами из жизни. Такого рода свидетельство взбудоражило западную компьютерную прессу.
Виновником беспокойства стала американская компания Coverity, а причиной - опубликованный ею отчёт о продолжительном исследовании исходных текстов ядра операционной системы Linux. Потратив четыре года на совершенствование методов выявления ошибок в программном коде, эксперты Coverity "прошерстили" около шести миллионов строк кода ядра версии 2.6 и обнаружили в нём немногим менее одной тысячи ошибок. Работа проделана большей частью в автоматическом режиме специальной программой [SWAT], основные принципы функционирования которой основатели Coverity сформулировали ещё в бытность свою студентами Стэнфордского университета. Задача SWAT - выявление ошибок в статическом коде C и C++, так что доступные всем и вся исходники ядра свободной ОС пришлись как нельзя кстати. Впрочем, интересно другое - много это или мало, тысяча ошибок на почти шесть миллионов строк? Сравнивая с известной работой другой группы исследователей (Carnegie Mellon University), анализировавших качество кода некоторых проприетарных программ, можно утверждать: весьма умеренно. По самым скромным оценкам, в ядре Linux ошибки встречаются в шесть раз реже, нежели в программах с закрытым кодом.
По прочтении всего этого возникают два вопроса. Первый: если специалисты Coverity сумели отыскать аж тысячу ошибок в ядре Linux, которое принадлежит всем нам в равной степени, почему бы не сделать следующий шаг и не опубликовать результаты поисков, дабы разработчики ядра смогли устранить недоработки? И не станет ли Linux в результате идеальной системой - ведь все ошибки будут устранены? На самом деле публикация результатов ведётся с апреля и к настоящему моменту большая часть багов, открытых Coverity, уже исправлена. Но предполагать, что устранение выявленных программным инструментом ошибок сделает продукт идеальным по меньшей мере наивно. Алгоритмы автоматической идентификации багов в исходных текстах программ за последние несколько лет сделали большой шаг вперёд и в настоящий момент тот же SWAT от Coverity на каждые четыре ошибки выдаёт лишь одну ложную. Но и по сей день "автоматика" умеет выявлять лишь самые простые, можно сказать очевидные баги. Такие автоверификаторы используются многими крупными компаниями, среди которых и Microsoft, но качество кода Windows всё ещё невообразимо далеко от идеального. Так что не следует ожидать каких-то чудес и по отношению к Linux.
Разве исследование Coverity единственное? - Конечно, нет. Велись аналогичные изыскания и другими экспертными группами, часть из которых подтверждает выводы Coverity, часть опровергает их. Но у Coverity есть одно неоспоримое преимущество, о котором уже шла речь выше: результаты работы этой компании опубликованы и уже использованы с ощутимой пользой для компьютерного сообщества. Так что оснований доверять сегодняшнему отчёту больше. А у линуксоидов появился ещё один повод для гордости.
Динамика появления новых ошибок в Linux ядре.
Представлена интересная статистика (http://kerneltrap.org/node/8414): ежедневно в Linux ядро вливается в среднем 65 патчей, 500 коммитов в неделю, 2000 изменений в месяц и 25000 в год.
Такой объем нового кода неизбежно порождает новые ошибки, после анализа работы за 100 дней было выявлено, что раз в 4 дня новые изменения приводят к нарушению работоспособности старых систем.
Также доступна статья "Future of Enterprise Linux kernels" (http://www.kroah.com/log/linux/enterprise_kernel_future.html) в которой Greg Kroah-Hartman рассказал об особенностях и проблемах подготовки "enterprise" версий Linux ядра (например, ядер входящих в состав RedHat или SuSE).
Замечательный мир Linux
Казалось бы, только вчера мы запускали наши первые Linux -системы с ядром 2.4, а вот уж время пролетело, озимые заколосились и... команда разработчиков ядра приблизилась к завершению работы над новой версией ядра — 2.6. В этом документе будут описаны новые особенности ядра 2.6 (с сильным уклоном к i386-порту Linux ).
Следует иметь в виду, что некоторые из особенностей, описанные здесь, могут быть удалены или помечены как "экспериментальные" в актуальных выпусках ядра 2.6. Однако на текущий момент развитие ядра имеет статус “feature-freeze”, т.е. никакие новые возможности более не добавляются в ядро, и это радует нас, потому что харашо: финальный релиз не будет сильно отличаться от того, что описано тут. Также следует учесть, что некоторые из "новых" особенностей, обсуждаемых здесь, возможно, были портированы задним числом в Linux 2.4 после их появления в Linux 2.6, официально или дистрибутором.
Opteron — 64 бита для потребителя
Другой процессор, поддержка которого была интегрирована при развитии ветки 2.4.x, но заслуживающая упоминания здесь — поддержка Linux’ом процессоров AMD Opteron (основанных на архитектуре AMD64.) Это новый чип обратно совместим с существующими процессорами-клонами Intel и получивший даже “обратную” поддержку от Microsoft. В то время как более поздние редакции ядра 2.4 поддерживали этот процессор, все же были ограничения, не позволявшие широкое использование этих систем. Наиболее критичным при использовании в высокопроизводительных системах является то, что каждая задача ограничена 512 Мбайтами памяти. Кроме того была улучшена поддержка х86 (32-разрядных) программ.
Масштабирование вверх — NUMA и большое железо
Новый выпуск ядра включает особенности, которые делают более приемлемым его использование на крупных серверах (некоторые работают на i386 процессорах, некоторые нет). Поскольку данная отрасль относительно в новинку для Linux, многое еще предстоит сделать (в направлении оптимизации).
Важнейшим изменением в этом отношении стала поддержка серверов с NUMA. NUMA (Non-Uniform Memory Access, неоднородный доступ к памяти) является шагом в сторону от традиционного SMP в многопроцессорном мире, и это шаг вперед к эффективности систем, имеющих много процессоров. SMP-системы были разработаны с некоторыми ограничениями, характерными для их однопроцессорных коллег. Одним из существенных ограничений при выборе такого дизайна является то, что он основан на едином пуле памяти, который разделяют между собой все процессоры системы. В многопроцессорных системах это приводит к сильной конкуренции между процессорами, работающими на одной шине памяти. NUMA-серверы обходят данную проблему, представляя следующую концепцию: отдельному процессору предоставляется часть памяти, не доступная другим процессорам . Один простой путь (технически довольно корректный) состоит в том, чтобы представить, что вы имеете систему с платами расширения, содержащими процессоры, память и, возможно, другие компоненты (ввода-вывода и др.). Некоторое количество таких плат в системе могут “свободно” общаться между собой, каждый процессор имеет свободный доступ к локальной памяти (кроме того доступ к памяти на плате процессора быстрее чем к памяти на выделенной плате). Во многом архитектура NUMA является примером очень сильно связанного кластера.
Чтобы должным образом поддерживать новые NUMA-машины, необходимо было адаптировать Linux сразу в нескольких направлениях, чтобы новая модель стала эффективной. Для начала был создан API внутренней топологии, позволяющий ядру понять, как один процессор или один пул памяти связаны с устройствами ввода-вывода и как они связаны между собой. Опираясь на эту информацию, планировщик процессов Линукса теперь может понять эти взаимосвязи и оптимизировать выполнение задач с наиболее выгодным распределением локальных ресурсов. Кроме того, многие NUMA-машины построены таким образом, что имеют “дыры” в линейном адресном пространстве между узлами. Новое ядро решает эту проблему разумным способом. Было сделано множество других внутренних изменений, которые позволят Linux работать с этими новыми хай-энд машинами. В течение следующего года мы можем ожидать новые доработки и усовершенствования поддержки этих высокопроизводительных систем.
Hyperthreading
Хотя это не новинка Linux 2.6., поддержка Hyperthreading появилась еще в ядре 2.4.17, данная возможность описывается здесь потому, что начальный релиз 2.4. не поддерживал Hyperthreading, а также потому, что с того времени сделано много серьезных изменений). Hyperthreading — это способность одного процессора маскироваться для ОС под два или больше. Естественно, процессор, претендующий быть “двумя”, все же остается одним процессором и производительность растет не сильно.
Вопросы размера — усовершенствование масштабируемости
Кроме поддержки NUMA, в новом ядре реализованы и другие изменения, касающиеся серверов Intel, стоящих на верхушке “пищевой цепочки”. Первое — это полная поддержка PAE (Physical Address Extension, расширение физического адреса), которая позволяет новейшим 32-битным х86 системам адресовать до 64 Гбайт ОЗУ. Кроме того, посредством улучшенной поддержки APIC и других изменений, было существенно улучшено распределение IRQ в многопроцессорных системах.
Были расширены пределы некоторых внутренних ограничений. Так, количество уникальных пользователей и групп системы возросло с 65000 до более чем 4 миллиардов (с 16 до 32 бит). Это позволит Linux работать на больших файл-серверах и серверах аутентификации, где ранее, возможно, поджимали предыдущие ограничения. Точно так, максимальное количество PID-ов было увеличено с 32000 до 1 миллиарда. Это изменение, совместно с другими усовершенствованиями в PID-подсистеме, улучшит производительность запуска приложений на очень занятых или долго работающих системах. Хотя максимальное количество открытых файлов не было увеличено, ядро 2.6. более не требует вашего вмешательства в установление этого предела заблаговременно, а самомасштабирует это количество. И, наконец, Linux 2.6. включает улучшенную поддержку 64 бит на блочных устройствах, поддерживающих работу в данном режиме, даже на 32-битных платформах, таких, как i386. Это позволяет создавать файловые системы, размером до 2 Тбайт.
Интерактивность и скорость реакции ядра
Главное внутреннее изменение, представленное в ядре 2.6. и значение которого не может быть преуменьшено, это то, что теперь само ядро является выгружаемым. В предыдущих версиях Linux, когда ОС выполняла что-либо в ядре, она не могла быть прервана (на многопроцессорных машинах это было истинно в отношении каждого процессора). Начиная с ядра 2.6., пользовательская задача может прервать работу ядра даже если оно выполняет нечто сложное (чтобы избежать вызванных этим явных коллизий, ядро имеет части, которые не могут быть прерваны в процессе выполнения). Основной выигрыш, достигнутый этими изменениями, заключается в том, что улучшается интерактивная производительность (например при работе пользователя настольной системы) и таким образом система становится более чувствительной к таким вещам, как пользовательский ввод.
Другим изменением, позволившим Linux стать более интерактивной ОС в отношении приложений, поддерживающих такую интерактивность, стала поддержка новых "futexes" (Fast User-Space Mutexes, быстрые семафоры пользовательского пространства). Futexes — это возможность, с помощью которой множественные процессы и нити могут выстраивать последовательность событий так, что они не будут наступать друг другу на пятки (состояние гонки). В отличие от традиционных операций взаимоисключения, поддерживаемых большинством библиотек распараллеливания процессов, данный способ частично базируется на поддержке ядра (но только в случае возникновения разногласий). Он также поддерживает систему приоритетов, позволяющую приложениям или нитям с более высоким приоритетом получить первоочередной доступ к запрошенным ресурсам. Программное определение приоритета задач позволило получить более интерактивную систему, что может быть очень важно в критичных ко времени приложениях.
Серьезным изменениям подверглась подсистема ввода-вывода, сделав его более чувствительным независимо от степени загрузки. Эти изменения включают полностью переписанную подсистему планирования ввода-вывода, кода ядра, определяющего какие процессы будут производить чтение с устройств и когда. Учитывая более раннюю оптимизацию, которая обеспечивала чтение в порядке, наилучшем относительно оборудования, переписанный код обеспечивает исключение долговременного простоя процессов в ожидании ввода-вывода.
И хотя разработчики приложений реального времени получают максимальный выигрыш от этих изменений, 2.6. все же не является ядром реального времени. Однако эти и другие изменения делают возможным создание основы для полностью RT-версии Linux , и уже есть сторонние патчи (пока не утвержденные и не включенные в официальный выпуск ядра), которые обеспечивают поддержку пользователей и разработчиков, нуждающихся в этом сейчас.
Подсистема модулей и драйверы устройств
Первое и наиболее очевидное изменение в драйверах ядра 2.6. — это изменение расширений файлов. Вместо бывшего “.о” (стандартное расширение для объектных файлов) теперь используется расширение “.kо” (kernel object). Это лишь косметическое изменение, делающее более ясным то, что модули не являются промежуточными объектными файлами.
Абсолютно не косметическое изменение — огромная работа, проделанная для устранения состояний гонки, которые имели место в коде многих предыдущих ревизий. Загвоздка в том, что какое-либо устройство может обратиться к модулю в процессе его выгрузки, но уже после того, как модуль проверит, не используется ли он. Новый код модульной части ядра сводит такие состояния к минимуму.
Улучшенная прозрачность — еще одна возможность новой подсистемы модулей. Почти во всех предыдущих версиях Линукса модули были достаточно умными для определения устройств, поддерживающих определение ID устройства сканированием шин (таких как PCI, ISA PnP, и PC Card). В ядре 2.6. большая часть такой поддержки была стандартизована и вынесена вне ядра, что позволило внешним программам и загрузчикам модулей определять, какие устройства поддерживает конкретный модуль. Это позволит различным программам управления оборудованием (таким, как kudzu) принимать интеллектуальные решения об оборудовании, даже если они его не “знают”. И если вы уверены, вы можете заставить драйвер попытаться работать с устройством, которое он не поддерживает (посредством интерфейса новой файловой системы sys, описанной ниже).
Linux используется в лучшем случае в десятки раз реже, нежели Windows, внимания к ней привлечено меньше, отчего и уязвимости обнаруживаются сравнительно реже. Однако эта осторожная точка зрения не учитывает одного важного нюанса: принципиальной разницы в подходах к разработке проприетарного и свободного софта. В случае с программным обеспечением с закрытым кодом разработчикам чаще всего платят за их труд. В случае с open source-продуктами девелоперы трудятся либо из чистого интереса, либо получая вознаграждение не напрямую; кроме того, они неизбежно взаимодействуют с массой разработчиков разных интересов и квалификации - в силу открытости исходных текстов. Так почему бы свободному программному обеспечению и в самом деле не содержать меньше ошибок? Эта сладкая для приверженцев идеи открытого кода теория безусловно имеет право на жизнь, но что самое интересное - подтверждается реальными фактами из жизни. Такого рода свидетельство взбудоражило западную компьютерную прессу.
Виновником беспокойства стала американская компания Coverity, а причиной - опубликованный ею отчёт о продолжительном исследовании исходных текстов ядра операционной системы Linux. Потратив четыре года на совершенствование методов выявления ошибок в программном коде, эксперты Coverity "прошерстили" около шести миллионов строк кода ядра версии 2.6 и обнаружили в нём немногим менее одной тысячи ошибок. Работа проделана большей частью в автоматическом режиме специальной программой [SWAT], основные принципы функционирования которой основатели Coverity сформулировали ещё в бытность свою студентами Стэнфордского университета. Задача SWAT - выявление ошибок в статическом коде C и C++, так что доступные всем и вся исходники ядра свободной ОС пришлись как нельзя кстати. Впрочем, интересно другое - много это или мало, тысяча ошибок на почти шесть миллионов строк? Сравнивая с известной работой другой группы исследователей (Carnegie Mellon University), анализировавших качество кода некоторых проприетарных программ, можно утверждать: весьма умеренно. По самым скромным оценкам, в ядре Linux ошибки встречаются в шесть раз реже, нежели в программах с закрытым кодом.
По прочтении всего этого возникают два вопроса. Первый: если специалисты Coverity сумели отыскать аж тысячу ошибок в ядре Linux, которое принадлежит всем нам в равной степени, почему бы не сделать следующий шаг и не опубликовать результаты поисков, дабы разработчики ядра смогли устранить недоработки? И не станет ли Linux в результате идеальной системой - ведь все ошибки будут устранены? На самом деле публикация результатов ведётся с апреля и к настоящему моменту большая часть багов, открытых Coverity, уже исправлена. Но предполагать, что устранение выявленных программным инструментом ошибок сделает продукт идеальным по меньшей мере наивно. Алгоритмы автоматической идентификации багов в исходных текстах программ за последние несколько лет сделали большой шаг вперёд и в настоящий момент тот же SWAT от Coverity на каждые четыре ошибки выдаёт лишь одну ложную. Но и по сей день "автоматика" умеет выявлять лишь самые простые, можно сказать очевидные баги. Такие автоверификаторы используются многими крупными компаниями, среди которых и Microsoft, но качество кода Windows всё ещё невообразимо далеко от идеального. Так что не следует ожидать каких-то чудес и по отношению к Linux.
Разве исследование Coverity единственное? - Конечно, нет. Велись аналогичные изыскания и другими экспертными группами, часть из которых подтверждает выводы Coverity, часть опровергает их. Но у Coverity есть одно неоспоримое преимущество, о котором уже шла речь выше: результаты работы этой компании опубликованы и уже использованы с ощутимой пользой для компьютерного сообщества. Так что оснований доверять сегодняшнему отчёту больше. А у линуксоидов появился ещё один повод для гордости.
Динамика появления новых ошибок в Linux ядре.
Представлена интересная статистика (http://kerneltrap.org/node/8414): ежедневно в Linux ядро вливается в среднем 65 патчей, 500 коммитов в неделю, 2000 изменений в месяц и 25000 в год.
Такой объем нового кода неизбежно порождает новые ошибки, после анализа работы за 100 дней было выявлено, что раз в 4 дня новые изменения приводят к нарушению работоспособности старых систем.
Также доступна статья "Future of Enterprise Linux kernels" (http://www.kroah.com/log/linux/enterprise_kernel_future.html) в которой Greg Kroah-Hartman рассказал об особенностях и проблемах подготовки "enterprise" версий Linux ядра (например, ядер входящих в состав RedHat или SuSE).
Замечательный мир Linux
Казалось бы, только вчера мы запускали наши первые Linux -системы с ядром 2.4, а вот уж время пролетело, озимые заколосились и... команда разработчиков ядра приблизилась к завершению работы над новой версией ядра — 2.6. В этом документе будут описаны новые особенности ядра 2.6 (с сильным уклоном к i386-порту Linux ).
Следует иметь в виду, что некоторые из особенностей, описанные здесь, могут быть удалены или помечены как "экспериментальные" в актуальных выпусках ядра 2.6. Однако на текущий момент развитие ядра имеет статус “feature-freeze”, т.е. никакие новые возможности более не добавляются в ядро, и это радует нас, потому что харашо: финальный релиз не будет сильно отличаться от того, что описано тут. Также следует учесть, что некоторые из "новых" особенностей, обсуждаемых здесь, возможно, были портированы задним числом в Linux 2.4 после их появления в Linux 2.6, официально или дистрибутором.
Opteron — 64 бита для потребителя
Другой процессор, поддержка которого была интегрирована при развитии ветки 2.4.x, но заслуживающая упоминания здесь — поддержка Linux’ом процессоров AMD Opteron (основанных на архитектуре AMD64.) Это новый чип обратно совместим с существующими процессорами-клонами Intel и получивший даже “обратную” поддержку от Microsoft. В то время как более поздние редакции ядра 2.4 поддерживали этот процессор, все же были ограничения, не позволявшие широкое использование этих систем. Наиболее критичным при использовании в высокопроизводительных системах является то, что каждая задача ограничена 512 Мбайтами памяти. Кроме того была улучшена поддержка х86 (32-разрядных) программ.
Масштабирование вверх — NUMA и большое железо
Новый выпуск ядра включает особенности, которые делают более приемлемым его использование на крупных серверах (некоторые работают на i386 процессорах, некоторые нет). Поскольку данная отрасль относительно в новинку для Linux, многое еще предстоит сделать (в направлении оптимизации).
Важнейшим изменением в этом отношении стала поддержка серверов с NUMA. NUMA (Non-Uniform Memory Access, неоднородный доступ к памяти) является шагом в сторону от традиционного SMP в многопроцессорном мире, и это шаг вперед к эффективности систем, имеющих много процессоров. SMP-системы были разработаны с некоторыми ограничениями, характерными для их однопроцессорных коллег. Одним из существенных ограничений при выборе такого дизайна является то, что он основан на едином пуле памяти, который разделяют между собой все процессоры системы. В многопроцессорных системах это приводит к сильной конкуренции между процессорами, работающими на одной шине памяти. NUMA-серверы обходят данную проблему, представляя следующую концепцию: отдельному процессору предоставляется часть памяти, не доступная другим процессорам . Один простой путь (технически довольно корректный) состоит в том, чтобы представить, что вы имеете систему с платами расширения, содержащими процессоры, память и, возможно, другие компоненты (ввода-вывода и др.). Некоторое количество таких плат в системе могут “свободно” общаться между собой, каждый процессор имеет свободный доступ к локальной памяти (кроме того доступ к памяти на плате процессора быстрее чем к памяти на выделенной плате). Во многом архитектура NUMA является примером очень сильно связанного кластера.
Чтобы должным образом поддерживать новые NUMA-машины, необходимо было адаптировать Linux сразу в нескольких направлениях, чтобы новая модель стала эффективной. Для начала был создан API внутренней топологии, позволяющий ядру понять, как один процессор или один пул памяти связаны с устройствами ввода-вывода и как они связаны между собой. Опираясь на эту информацию, планировщик процессов Линукса теперь может понять эти взаимосвязи и оптимизировать выполнение задач с наиболее выгодным распределением локальных ресурсов. Кроме того, многие NUMA-машины построены таким образом, что имеют “дыры” в линейном адресном пространстве между узлами. Новое ядро решает эту проблему разумным способом. Было сделано множество других внутренних изменений, которые позволят Linux работать с этими новыми хай-энд машинами. В течение следующего года мы можем ожидать новые доработки и усовершенствования поддержки этих высокопроизводительных систем.
Hyperthreading
Хотя это не новинка Linux 2.6., поддержка Hyperthreading появилась еще в ядре 2.4.17, данная возможность описывается здесь потому, что начальный релиз 2.4. не поддерживал Hyperthreading, а также потому, что с того времени сделано много серьезных изменений). Hyperthreading — это способность одного процессора маскироваться для ОС под два или больше. Естественно, процессор, претендующий быть “двумя”, все же остается одним процессором и производительность растет не сильно.
Вопросы размера — усовершенствование масштабируемости
Кроме поддержки NUMA, в новом ядре реализованы и другие изменения, касающиеся серверов Intel, стоящих на верхушке “пищевой цепочки”. Первое — это полная поддержка PAE (Physical Address Extension, расширение физического адреса), которая позволяет новейшим 32-битным х86 системам адресовать до 64 Гбайт ОЗУ. Кроме того, посредством улучшенной поддержки APIC и других изменений, было существенно улучшено распределение IRQ в многопроцессорных системах.
Были расширены пределы некоторых внутренних ограничений. Так, количество уникальных пользователей и групп системы возросло с 65000 до более чем 4 миллиардов (с 16 до 32 бит). Это позволит Linux работать на больших файл-серверах и серверах аутентификации, где ранее, возможно, поджимали предыдущие ограничения. Точно так, максимальное количество PID-ов было увеличено с 32000 до 1 миллиарда. Это изменение, совместно с другими усовершенствованиями в PID-подсистеме, улучшит производительность запуска приложений на очень занятых или долго работающих системах. Хотя максимальное количество открытых файлов не было увеличено, ядро 2.6. более не требует вашего вмешательства в установление этого предела заблаговременно, а самомасштабирует это количество. И, наконец, Linux 2.6. включает улучшенную поддержку 64 бит на блочных устройствах, поддерживающих работу в данном режиме, даже на 32-битных платформах, таких, как i386. Это позволяет создавать файловые системы, размером до 2 Тбайт.
Интерактивность и скорость реакции ядра
Главное внутреннее изменение, представленное в ядре 2.6. и значение которого не может быть преуменьшено, это то, что теперь само ядро является выгружаемым. В предыдущих версиях Linux, когда ОС выполняла что-либо в ядре, она не могла быть прервана (на многопроцессорных машинах это было истинно в отношении каждого процессора). Начиная с ядра 2.6., пользовательская задача может прервать работу ядра даже если оно выполняет нечто сложное (чтобы избежать вызванных этим явных коллизий, ядро имеет части, которые не могут быть прерваны в процессе выполнения). Основной выигрыш, достигнутый этими изменениями, заключается в том, что улучшается интерактивная производительность (например при работе пользователя настольной системы) и таким образом система становится более чувствительной к таким вещам, как пользовательский ввод.
Другим изменением, позволившим Linux стать более интерактивной ОС в отношении приложений, поддерживающих такую интерактивность, стала поддержка новых "futexes" (Fast User-Space Mutexes, быстрые семафоры пользовательского пространства). Futexes — это возможность, с помощью которой множественные процессы и нити могут выстраивать последовательность событий так, что они не будут наступать друг другу на пятки (состояние гонки). В отличие от традиционных операций взаимоисключения, поддерживаемых большинством библиотек распараллеливания процессов, данный способ частично базируется на поддержке ядра (но только в случае возникновения разногласий). Он также поддерживает систему приоритетов, позволяющую приложениям или нитям с более высоким приоритетом получить первоочередной доступ к запрошенным ресурсам. Программное определение приоритета задач позволило получить более интерактивную систему, что может быть очень важно в критичных ко времени приложениях.
Серьезным изменениям подверглась подсистема ввода-вывода, сделав его более чувствительным независимо от степени загрузки. Эти изменения включают полностью переписанную подсистему планирования ввода-вывода, кода ядра, определяющего какие процессы будут производить чтение с устройств и когда. Учитывая более раннюю оптимизацию, которая обеспечивала чтение в порядке, наилучшем относительно оборудования, переписанный код обеспечивает исключение долговременного простоя процессов в ожидании ввода-вывода.
И хотя разработчики приложений реального времени получают максимальный выигрыш от этих изменений, 2.6. все же не является ядром реального времени. Однако эти и другие изменения делают возможным создание основы для полностью RT-версии Linux , и уже есть сторонние патчи (пока не утвержденные и не включенные в официальный выпуск ядра), которые обеспечивают поддержку пользователей и разработчиков, нуждающихся в этом сейчас.
Подсистема модулей и драйверы устройств
Первое и наиболее очевидное изменение в драйверах ядра 2.6. — это изменение расширений файлов. Вместо бывшего “.о” (стандартное расширение для объектных файлов) теперь используется расширение “.kо” (kernel object). Это лишь косметическое изменение, делающее более ясным то, что модули не являются промежуточными объектными файлами.
Абсолютно не косметическое изменение — огромная работа, проделанная для устранения состояний гонки, которые имели место в коде многих предыдущих ревизий. Загвоздка в том, что какое-либо устройство может обратиться к модулю в процессе его выгрузки, но уже после того, как модуль проверит, не используется ли он. Новый код модульной части ядра сводит такие состояния к минимуму.
Улучшенная прозрачность — еще одна возможность новой подсистемы модулей. Почти во всех предыдущих версиях Линукса модули были достаточно умными для определения устройств, поддерживающих определение ID устройства сканированием шин (таких как PCI, ISA PnP, и PC Card). В ядре 2.6. большая часть такой поддержки была стандартизована и вынесена вне ядра, что позволило внешним программам и загрузчикам модулей определять, какие устройства поддерживает конкретный модуль. Это позволит различным программам управления оборудованием (таким, как kudzu) принимать интеллектуальные решения об оборудовании, даже если они его не “знают”. И если вы уверены, вы можете заставить драйвер попытаться работать с устройством, которое он не поддерживает (посредством интерфейса новой файловой системы sys, описанной ниже).