Первое знакомство с ядром линукс версии 3.3 и 3.4

Original author: M. Tim Jones
  • Translation
Далее — перевод статьи с сайта IBM. Вряд ли вы узнаете что-то принципиально новое из неё. Данную статью хорошо использовать как отправную точку для чтения об интересных или ранее неизвестных вам особенностях Линукс. Часть ссылок я привёл в тексте статьи курсивом, часть можно увидеть в конце оригинальной статьи. Мои пояснения или комментарии выделены курсивом.

В релизы ядра Линукс версий 3.3 и 3.4 вошло впечатляющее количество улучшений. Однако эти релизы не просто развитие ядра, но зловещий рубеж на пути этого развития.
Релиз версии 3.3 — первый релиз ядра линукс, объём которого превысил 15 миллионов строк (пусть даже по откровенно кривому способу измерения). Если вы вычтете изменяемую, непостоянную часть кода (различные драйвера, платформозависимый код и различные утилиты), число строк падает немного ниже 4 миллионов — левиафан собственной персоной.

Зловещее в этом рубеже и скорость, с которой растёт ядро (пятидесятипроцентный рост с 2008 года), и то что этот рост может негативно повлиять на ядро (как с точки зрения производительности, так и с точки зрения возможностей ядра). Возможности и производительность обычно не измеряют «попатчево», так что в ядро вполне может попасть баг, который будет сохраняться некоторое время (например, проблема со PCIe ASPM, которая была в ядре почти год, но была исправлена в версии 3.3 Описание www.pcworld.com/businesscenter/article/244277/new_kernel_patch_slashes_linuxs_power_appetite.html и патч lkml.org/lkml/2011/11/10/467)

Менее чем за 21 год линукс вырос с 10000 строк кода до более чем 15 миллионов. Кроме того, большая часть этого кода находится в поддереве драйверов, а сложность ядра увеличивается с его размерами. Рано или поздно, это расширение должно вылиться в изменения, которые сделают ядро более простым. Как с точки зрения кода, так и с точки зрения поддержки этого кода.



Как показано на иллюстрации номер 1, ядро быстро выросло с момента релиза 2.4 в 2001 году (с 3 377 902 строк до 15 998 651 строки в 2012). В течение этого срока, каждый год в ядро добавлялось около миллиона строк. Это ошеломляющая иллюстрация и должна внушать страх каждому разработчику софта.

Цитируют слова самого Торвальдса, о его озабоченности поддержкой ядра, по мере его роста. С 4 миллионами строк кода, которые составляют саму суть ядра, текущая система управления исходными кодами ядра может потребовать улучшения.

Интеграция андроида.


Самая большая новость ядра 3.3 — включение в основную ветку ядра Google Android. Эта интеграция продолжится в ядре 3.4, но уже сейчас в ядре достаточно кода от андроида, чтобы поддерживалась загрузка андроида в user-space'е. Ядро андроида — форк ядра Линукс, с несколькими особенностями. Эти особенности введены для эффективной работы мобильных устройств, которые сильно ограничены в доступном питании. Кроме того, в андроиде основной упор делается на архитектуру ARM, хотя поддержка x86 тоже присутствует (например, для проекта Google TV).

Проблемы взаимодейтсвия между мейнтейнерами Линукса и Гуглом привели к тому, что Андроид разрабатывался несколько лет отдельно. Зимой 2011-2012 года был создан проект Android Mainlining, чья цель — интегрировать драйвера и новые функции ядра Андроида в основное дерево исходников Линукса. Проделанная работа была представлена широкой публике в ядре 3.3 и будет продолжена в последующих релизах.

Андроид внёс несколько улучшений в Линукс, которые были необходимы, чтобы быть конкурентноспособным в мобильной среде. В качестве примера можно привести быстрые механизмы межпроцессорного взаимодействия (Fast IPC), улучшенные механизмы управления памятью и решение проблемы управления большими непрерывными областями памяти.

Binder — драйвер, который стал ответом Андроида стандартным механизмам IPC. Разработчики Андроида запросто могли использовать существующий код, однако разработка Binder'а предоставила несколько уникальных «фишек», которые раньше были недоступны (передача сообщений без копирования и передача «мандатов». Подробнее можно ознакомиться по ссылке lwn.net/Articles/466304 ). В Андроиде приложения никогда не выходят привычным образом, они работают до тех пор, пока ядро не завершит их. Для оптимизации использования памяти существует механизм под названием Shrinker. Приложения регистрируют функцию, которая при вызове минимизирует количество используемой ими памяти. Ядро вызывает эти функции, когда ему начинает не хватать памяти. Другой механизм, который перекочевал из Андроида — Pmem. Этот механизм позволяет выделять физически непрерывный участок памяти. Подобная функция используется, например, при работе фотокамеры в телефонах. В рамках этого механизма существует API в пространстве пользователя, с помощью которого можно получить от системы непрерывный участок памяти. Кроме этих механизмов, из Андроида были перенесены и другие функции, специфичные для мобильных устройств.

Некоторые механизмы ещё не попали в ядро. Например, wakelocks — механизм управления питанием, который позволяет отдельным программам не давать системе входить в состояние пониженного энергопотребления (например, если идёт апдейт). Это, конечно, не помешает Андроиду загрузиться, однако может привести к быстрому пожиранию батареи.

Слияние Андроида с основной веткой разработки ядра Линукс — ещё одна иллюстрация гибкости Линукса. От встроенных и мобильных систем, до крупнейших в мире мейнфреймов и суперкомьютеров: Линукс прижился везде. И Линукс продолжает своё развитие как универсальная система на более чем 300 миллионах мобильных устройств.

Open vSwitch


Линукс продолжает быть самой популярной платформой виртуализации. Линукс не только операционная система мирового уровня, но так же и гипервизор мирового уровня. Внесение Open vSwitch в основную ветку ядра подтверждает этот статус для тех пользователей, который используют линукс как платформу виртуализации и предоставляют услуги IaaS на линуксе.

Виртуальный коммутатор это не что иное как программная реализация аппаратного коммутатора. Напомню на всякий случай, что платформа виртуализации (в том виде, как сделано в KVM или Xen) позволяет вам запускать несколько копий операционных систем (в роли виртуальных машин) на гипервизоре, который управляет доступом к физическим ресурсам машины. Введение виртуального коммутатора расширяет эту абстракцию, вводя новые формы сетевой инфраструктуры. Виртуальный коммутатор предоставляет эффективные средства для виртуальных машин для взаимодействия друг с другом по виртуальной сети. Open vSwitch расширяет функции виртуального коммутатора, позволяя объединять виртуальные сети нескольких гипервизоров. Таким образом, виртуальные машины могут взаимодействовать через виртуальную сеть с машинами, находящимися на других гипервизорах.

Внутри Open vSwitch реализован широкий набор функций для виртуализации сети. Среди этих функций: QoS, vlan'ы, фильтрация и изоляция трафика, а так же набор протоколов для мониторинга и управления (такие как OpenFlow и NetFlow). Несмотря на то, что в линуксе уже была реализация виртуальных коммутаторов (Linux Bridge), Open vSwitch намного более функциональное решение и следовательно — желанное дополнение.

Изменения файловых систем.


В релизе 3.3 внесены некоторые изменения в ряд файловых систем, которые будут актуальны как для пользователей, так и для разработчиков. Для пользователей, это онлайн изменение размеров ext4 томов, посредством контроля операций ввода вывода (вызов ioctl с флагом «EXT4_IOC_RESIZE_FS»). Под «онлайн» понимается то, что система остаётся в рабочем состоянии. Кроме того, теперь вся операция изменения размера производится в ядре, что ускоряет её.

Был переписан механизм балансировки для btrfs. Теперь он поддерживает приостановку и возобновление работы. Этот механизм используется для изменения структуры метаднных в таких случаях, например, как добавление нового жёсткого диска. Улучшение btrfs продолжилось в релизе 3.4, в котором была представлена утилита восстановления данных с повреждённых томов (btrfs-restore). Кроме того, в релиз 3.4 были внесены некоторые изменения, которые улучшили быстродействие и обработку ошибок в btrfs: вместо некоторых сообщений об ошибках, теперь элегатная обработка этих самых ошибок. До релиза 3.4 btrfs из-за механизма COW была плохо совместима с Linux virtual memory manager (последний имел тенденцию кэшировать уже ненужные btrfs страницы на слишком долгое время). Была проведена доработка, чтобы излечить этот недостаток. (исправлено в соответствии с juick.com/thegreatz/1982110#5 )

Реализация RAID так же была изменена. Теперь программная реализация RAID поддерживает «горячую замену»: данные с одного тома, могут быть перенесены на другой том, при этом первый позднее можно удалить из массива без потери данных. Управление этой функцией осуществляется через всем знакомый mdadm.
И наконец в релизе 3.4 добавленена поддержка файловой системы QNX4 (пока в режиме «только чтение»).

Разработчики получили возможность вносить ошибки в работу сетевой файловой системы (NFS), чтобы проверять возможность клиента восстанавливаться после этих ошибок (механизм работает через sysfs). Для разработчиков brtfs была добавлена утилита проверки целостности файловой системы, которая может быть использована для обнаружения неверных запросов на запись, что позволит быстрее исправлять проблемы.

Улучшения в работе сети.


Так же в релиз 3.3 было внесено несколько передовых изменений.

Для низколатентных сред (такие как суперкомпьютерные вычисления) была введена возможность предоставлять доступ к устройствам по протоколу SCSI RDMA (очень кратко можно прочесть тут: ru.wikipedia.org/wiki/InfiniBand ). SCSI RDMA это протокол, который позволяет вам использовать RDMA как транспорт для блочных устройств. RDMA поддерживается InfiniBand'ом и достаточно распространён в среде суперкомпьютерных вычислений.

Был модифицирован планировщик пакетов RED (Random Early Detection). Был изменён алгоритм работы в соответсвии с предложениями Салли Флойда (Sally Floyd), Рамакришны Гаммади (Ramakrishna Gummadi) и Скотта Шенкера (Scott Shenker). Новый планировщик получил название ARED (Adaptive RED, принято переводить калькой «адаптивный» ;). RED отслеживает средний размер очереди и отбрасываемых пакетов, основываясь на статистической вероятности. При пустой очереди, все пакеты принимаются. При заполненности очереди выше порогового значения, почти все пакеты отбрасываются. ARED решает в каждом отдельном случае, сделать ли RED более или менее агрессивным, основываясь на наблюдениях за средней длиной очереди. Больше об ARED можно узнать из материалов по ссылке: icir.org/floyd/papers/adaptiveRed.pdf .

Так же в релиз 3.3 была добавлена новая реализация для замены устаревшего драйвера бондинга. Группировка нескольких физических интерфейсов в один виртуальный, позволяет создавать интерфейсы с большей надёжность и пропускной способностью (в соответствии, например, с протоколом 802.1AX). На текущий момент поддерживается два режима работы нового механизма: простое распределение пакетов по правилу round-robin или active-backup. В первом случае пакеты шлются по очереди с каждого из физических интерфейсов. Во втором случае данные передаются по одному физическому интерфейсу и при его «падении» — по запасному.

Среди большого количество сделанных изменений, можно также выделить интересное дополнение к реализации cgroups: добавлена реализация ограничений буферов для ТСР. cgroups используются различными способами. В том числе — для ограничения ресурсов виртуальных машин. После этого изменения стала доступна более тонка настройка использования системной памяти, а следовательно — более детальное управление системой в целом.

Другие интересные изменения


В релиз ядра 3.3 также попали изменения не связанные с файловыми системами или сетью. Была добавлена поддержка новой архитектуры: в основную ветку ядра внесён код проекта, по поддержке процесса C6x от Texas Instruments. С6х это процессоры VLIW архитектуры с одним или несколькими ядрами. Эти процессоры не поддерживают такие функции как SMP и когерентность кэша. Кроме того, в них нет блока управления памятью (MMU). Несмотря на эти недостатки, процессоры серии С6х имеют широкий набор периферии и дополнительных блоков, выполненных непосредственно на чипе (например, для быстрого преобразования Фурье).
В релиз 3.4 включена поддержка последних GPU, таких как Nvidia Kepler и последние Radeon'ы и Trinity от AMD

В архитектуре ARM теперь поддерживается расширение LPAE (PAE для работы с памятью до 1ТБ. Подробнее, например, в пдф со страницы www.linux-arm.info/index.php/130-linux-support-for-arm-lpae ). Кроме того, включена поддержка однокристальных систем от Nvidia (Tegra 3). Эти изменения позволяют процессорам ARM конкурировать с процессорами от Интел в сегменте серверов с низким энергопотреблением. Были сделаны ряд изменений в реализацию работы AMD IOMMU, которые улучшили управление страницами памяти изменяемого размера и безопасность, с точки зрения доступа устройств к памяти. Виртуальные фукнции ввода-вывода расширяют возможности KVM по предоставлению устройств виртуальным машинам.Кроме того архитектура S390 была доработана для поддержки до 64ТБ оперативной памяти (против 1 ТБ в предыдущих версиях)

Блок мониторинга производительности получил виртуальный интерфейс для KVM. Таким образом, теперь гостевые ОС могут отслеживать производительность на своей платформе. В рамках этого мониторинга доступны такие метрики, как «количество выполненых инструкций (retired instructions), попадания и промахи по кэшу, а также успешность предсказания переходов. Другим полезным нововведением является функция „безопасного сброса“. Эта функция позволяет не просто пометить сектор в запросе как свободный, но полностью его удалить.
Различные драйвера ввода/вывода (blk, net, balloon и console) теперь поддерживают ACPI и S4 sleep state, что означает, что теперь гостевые ВМ на Xen'е можно гибернировать.

Для отладки сложных проблем с повреждением памяти была добавлена новая опция конфигурации CONFIG_DEBUG_PAGEALLOC. При её включении будет отслеживаться доступ процессора к неаллоцированным страницам. Включение этой опции, естественно, приведёт к снижению производительности.

Взгляд в будущее.


Линукс продолжает развиваться и в то время как релиз 3.4 уже вышел, релиз-кандидат 3.5 уже почти готов к выпуску в августе 2012.
В следующем релизе нас также ждёт много нового: в btrfs улучшен механизм обратной записи, в ext4 добавлена возможность хранить контрольные суммы, для определения манипуляций с данными. Линукс, возможно, скоро будет поддерживать предоставление доступа к своим устройствам по протоколу SCSI по FireWire или SCSI по USB. Так же обещают включить поддержку обследования в user-space и использование SystemTap для анализа полученных данных. В будущем нас ждёт ещё много интересного, по мере развития ядра.
Share post

Similar posts

Comments 53

    +3
    О 3.5 в моей новости на ЛОРе: www.linux.org.ru/news/kernel/7982359

    Думаю, выпуск будет не в августе, а 23 июля, т.е., через неделю, как и обещает Торвальдс.
      +6
      на самом деле, мне не так важна дата выхода ядра: для меня в статье стали новостью такие слова как «open vSwitch», «Binder» и многие другие. Собственно за ради рассказать о них я и переводил текст ;)
        +2
        Спасибо! В последнее время пересборка ядра даёт мало информации о изменениях(( Раньше всё узнавал при конфигурировании, а сейчас вынужден ловить информацию из обзоров и рассылок.
          0
          Я пересобрав ядро несколько раз понял, что лучше сначала читать, потом пересобирать: часть опций доступны только при правильном сочетании других опций. Иногда эти сочетания не совсем очевидны.
            0
            Первые разы собирал и параллельно читал. Потом были и правки исходников, и сборки 2.4 со стандартными репами gentoo, ну а после разрабатываемой CLFS наступил дзен)) Просто, конфигурирование стало упрощаться с ростом размера исходника ядра.
      –1
      >но так же и гипервизор мирового уровня
      Увы, тут доминирует вмваря. FT-то в KVM пока нет, а для критически важных задач он необходим. Была какая-то попытка сделать FT, кажется kemari называлось, но о нем уже давно ничего не слышно. Ждем развития RHEV.
        +3
        в данном случае следует читать как «один из наиболее популярны», а не «лидирующий по рынку». У vmware есть свои «фишки», да. Но kvm вполне подходит для очень широкого круга пользователей.
        +3
        А 12309 исправили?
          0
          это достаточно хитры баг: насколько я знаю, уже несколько раз сообщалось о нормализации ситуации с heavy IO, но каждый раз находилась проблемная комбинация железа и софта.
          Сообщений об исправлении не видел в этот раз. Поживём — увидим.
            +4
            Я реально только этого и жду. Задолбало уже.
              0
              Не думаю, что попытка помочь вам будет уместная в комментариях…
              Ядро 3.3 вы можете попробовать уже сейчас. Кроме того, в попытках обойти этот баг были предложены ряд workaround'ов, которые многим помогают.
                +1
                Пишут, что исправили, хотя как на самом деле — еще непонятно.
                  0
                  На своем железе ни разу не наблюдал, зато воочию видел вчерась этот баг на Windows7, когда разворачивал образ раздела на винт!
                  0
                  У меня в 3.3 пропал, а в 3.4 еще и серьезно увеличилась скорость передачи данных.
                  0
                  достаточно кода от андроида, чтобы поддерживалась загрузка андроида в user-space

                  Это о вызове /init речь? Или что-то ещё? Всем остальным занимается сам init.
                    –1
                    Линукс не только операционная система мирового уровня

                    Это вообще не операционная система, это ядро.
                      +1
                      а «Ксерокс», «Памперс» и «Коньяк» — торговые марки.
                      В целом, я, конечно, в курсе. И с большим уважением отношусь к GNU, но… но как привык давным-давно называть GNU/Linux просто Linux, так до сих пор и называю.
                        +1
                        Сходите при возможности послушать Столлмана. Он очень хорошо и убедительно говорит о том, почему так делать не надо.
                          +1
                          Осторожнее со Столлманом, можно заразиться )
                            +1
                            Как будто в случае заражения произойдет что-то плохое :)
                            0
                            С одной стороны стараюсь говорить GNU/Linux, когда идёт более-менее точная терминология. С другой стороны, а что кроме GRUB и glibc из GNU можно отнести к ОС, а пользовательскому ПО? Ну, ещё bash с натягом. Всё.
                              0
                              Init, ifconfig, grep, cat и т.д. — можно ли это все считать частью linux? будет ли существовать linux без этого?
                                0
                                давайте пойдём по пунктам ;) У меня стоит убунту. Вы будете спорить с тем, что убунту — линукс?
                                init — в моём случае не GNU. В случае центоси он тоже свой, вроде. В списке www.gnu.org/software/ его нет.
                                ifconfig — устарел. Вместо него — ip. По факту, тоже не GNU писан
                                grep, cat, sed — имеют не GNU версии.

                                Ещё утилиты? Имейте в виду, всё что лицензируется под GPL, не обязательно пишется GNU или не имеет аналогов.
                                  0
                                  Да, пожалуй вы в чем-то правы. Полазал по сайту в поисках ответа почему же GNU/Linux, набрел на это: www.gnu.org/gnu/linux-and-gnu.html
                                  Пользуетесь вы GNU/Linux или нет, пожалуйста, не вводите общественность в заблуждение двусмысленным употреблением названия “Linux”. Linux — это ядро, одна из необходимых составляющих системы. Система в целом — это в основном система GNU с добавлением Linux. Когда вы говорите об этом сочетании, пожалуйста, называйте его “GNU/Linux”

                                  Вот это словосочетание «в основном», судя по всему, и стало причиной нашего спора :) Да, не все что есть в убунте, дебиане и прочих — GNU. Но основа (по крайней мере, как я понимаю, была таковой, ибо статья судя по всему старенькая) — GNU ПО + Linux ядро.
                                    0
                                    На самом деле, я бы с удовольствием послушал слова Столмана по этому поводу. Уж он то должен разбираться, почему же ГНУ/Линукс. Но с другой стороны — всегда есть что-то интереснее подобных споров ;)

                                    На самом деле, это в оригинале было «Linux». Будь там «GNU/Linux» я бы не исправлял ;) Лично мне, в некотором роде, всё равно, как называть этот софт.
                                      0
                                      Вот в этой фразе «система в целом» и кроется подвох. Какая система? Операционная система? Нет, grep, cat — не часть операционной системы. Это просто прикладные программы. Которые могут использоваться другими программами, но это не делает их частью ОС. Если говорим про систему в целом, дистрибутив, то опять же, кроме GNU есть Xorg, PulseAudio, Qt, KDE (в моём случае) и т.п. Их всех тоже надо упоминать?
                                  0
                                  А граница между пользовательским ПО и ОС вообще довольно расплывчата, особенно в свободных ОС.
                                  К тому же гном, например, является частью GNU.
                                    0
                                    Но grep, ни cat, ни тем более GIMP да GNOME — не часть ОС.
                                0
                                С таким подходом многие говорят, что не любят коньяк, хотя ни разу его и не пили. И внедрожкник — это джип, и шуруп это винт, и ещё много чего, что вообще-то является безграмотностью. Не стоит уподобляться.
                                  0
                                  давайте пойдём другим путём: Linux — это в первую очередь ядро. С этим вы согласны?
                                  Есть различные дистрибутивы линукса, где основа — ядро, а вокруг него собран некий набор программ. Правильно?
                                  Почему я должен идентифицировать группу систем на одном ядре по набору софта в некоторых из дистрибутивов?
                                    0
                                    По той же самой причине, по которой вы не называете Android Linux'ом, для удобства разделения. Если честно, не знаю другой ОС с ядром Linux, в которой набор использующихся библиотек и утилит GNU доведён до минимума. Применение термина Linux для обобщения Android и GNU/Linux ошибочно, так как у этих двух ОС мало общего в применении и использовании, и у последнего куда больше общего, например, с BSD.
                              +6
                              Для слежения за изменениями в ядре на h-online есть хорошая серия статей "Kernel Log". Также есть удобный сайт kernelnewbies.org.
                                0
                                А есть ли нечто подобное для ядра redhat?
                                0
                                А чем этот Binder лучше чем dbus и реально ли сделать dbus поверх binder'а?
                                  +1
                                  Совсем недавно уже обсуждали тут.
                                  0
                                  Кроме того, большая часть этого кода находится в поддереве драйверов, а сложность ядра увеличивается с его размерами.

                                  Когда уже производители железа сами начнут писать и поддерживать драйверы? Хотя тут, видимо, больше играет фактор нежелания делать код своих поделок отрытым.
                                    0
                                    Бояться, что «обосрут» или допишут и сделают лучше.
                                      +1
                                      даже если производитель поддерживает свой код сам, этот код, в какой-то мере, хранится в репозитории рядом с ядром. В данном случае речь скорее об управлении процессом разработки ядра в целом. Это огромная работа и совершенно неясно, кто этим будет заниматься в будущем.

                                      Кроме того, производители железа предлагают очень много изменений в ядро: linux пишется далеко не только энтузиастами-одиночками. В разработке участвует огромное количество таких компаний как HP, IBM, Oracle и другие. И именно эти компании, на самом деле, вносят самый существенный вклад в развитие линукса.
                                      0
                                      Мое первое знакомство с 3.3 заключалось в том, что я не смог откомпилировать под него модуль одной железяки. Пришлось долго и нудно ковыряться в коде.
                                        0
                                        Скомпилировали? Объяснение как это сделать выложили куда-нибудь? Если ещё нет — выложите ниже комментарием. Я уверен, это поможет многим.
                                          +1
                                          В моем случае все было довольно просто, т.к. модуль был несложным.
                                          С can-контроллером было как с 2.6.38, с модулем ядра камеры Apogee возился дольше, но по причине жуткого кода плюнул и стал работать через libusb, правда, не допилил еще <a href=«code.google.com/p/apogee-control/>управляющий софт — других дел уйма.
                                        0
                                        А может кто-нибудь объяснить, почему даже в новой версии Android 4.1 Jelly Bean такое «старое» ядро, если линукс версии 3.4 и быстрее и код андроида в себя включает???
                                          0
                                          Так даже в статье написано — на данный момент ещё не все фичи из ветки Андроида портированы в основную ветку. Те же wakelocks — андроид и так батарейкоед, а без них будет ещё хуже. Плюс, фактор тестирования — проще выпустить продукт на старом, менее быстром, но уже проверенном ядре, чем поставить самое новое, но ещё не прошедшее проверку.
                                            0
                                            Я думаю, это связано с тем, что андроид, в первую очередь — форк. У них есть стабильное дерево разработки в которое они вносят изменения. Очень тихо и спокойно. В отличии от настольных систем, ошибка с мобильными устройствами может стоить слишком дорого андроиду: кому нужен постоянно виснущий телефон, например?
                                            +1
                                            Боже, только не надо про RAID'ы в 3.x ядрах. Там жопа на жопе и жопой погоняет. Количество крешей и дедлоков на килограмм кода в linux-raid (хоть и исправленных) слишком даже для индусского кода. И да простит меня Нил, но такое предлагать в качестве системы повышения надёжности…
                                              0
                                              а ufm я помню жаловался на реализацию bonding'а. Но я думаю, либо уже допилили, либо ещё допилят: ни один enterprise дистрибутив на ядра 3.х пока не перешёл.
                                                0
                                                SLES 11 SP2 на 3.0 работает.
                                                  0
                                                  ну это друзья как-то жестят: переходить на «нулевую» версию чего-либо всегда рисковано. А в случае с ядром они наверняка огребут кучу неприятностей.
                                                  Ну разве что новелловцы уверены во всех изменениях, сделанных в ядре… Может они сами большую часть и сделали…
                                                    0
                                                    Вообще, 3.0 — это обычная 2.6.40, только переименованная. Переименование некоторые глюки спровоцировало (в дебиане, например, некоторое время была путаница с linux-2.6 мета-пакетом), но само по себе оно ничуть не мажорнее перехода от 2.6.38 на 2.6.39 (там больше изменений было).
                                              +2
                                              … Да, и буквально вчера словили в лаборатории кернел паник на btrfs.
                                                0
                                                «Open vSwitch расширяет функции виртуального коммутатора, позволяя объединять виртуальные сети нескольких гипервизоров.»

                                                Разве это не реализовано в XenServer?
                                                  0
                                                  быстрое гугление подсказывает, что в xenserver'е используется как раз open vswitch. Так что в xenserver'е действительно это реализовано.
                                                  0
                                                  " быстрые механизмы межпроцессорного взаимодействия (Fast IPC)"

                                                  Наверное, межпроцессного?

                                                  Only users with full accounts can post comments. Log in, please.