Журнал ядер - що приносить (3) інфраструктура c t magazine

Тенденції та новини | Журнал ядра

AppArmor, точки входу для антивірусних сканерів при доступі, нещодавно написана програма «Вбивство поза межею пам'яті» та основи коду Xen-Dom0 - одні з найважливіших нововведень у ядрі Linux 2.6.36. Завдяки деякій перебудові ця версія стає трохи меншою за свою попередницю, незважаючи на кілька сотень тисяч рядків нового коду.

У середу вранці Лінус Торвальдс випустив шосту попередню версію Linux 2.6.36. Він зазначив, що хотів би випустити 2.6.36 найближчим часом, але, можливо, врешті-решт вставити ще одну попередню версію.

Журнал ядра сприймає це як можливість продовжити міні-серію "Що приносить 2.6.36" з описом нововведень, що стосуються таких питань, як управління пам'яттю, система збірки та підтримка різних процесорів та системних архітектур. Перша частина серії стосувалася змін у графічному обладнанні, друга - щодо файлових систем, сховища та мережевого обладнання; четверта частина про зміни в ACPI, PCI, керуванні живленням та драйверах для USB, FireWire, V4L/DVB та Co. завершить міні-серію за кілька днів.

Безпека

Після того, як розробники AppArmor, розкриті компанією Novell в 2006 році, кілька років безуспішно намагалися включити код ядра для підвищення безпеки, версія 2.6.36 остаточно знайшла ядро (включаючи 1, 2, 3, документацію). Подібно до SELinux, AppArmor може обмежувати додатки певними діями; Тому зловмисники, які отримують доступ до системи через отвір у безпеці, наприклад у серверному програмному забезпеченні, можуть заподіяти лише обмежену шкоду.

AppArmor має репутацію легшого в адмініструванні, ніж SELinux. Останній надає перевагу Red Hat, а також використовується Red Hat Enterprise Linux (RHEL) та Fedora, серед інших. Novell тривалий час зосереджувався на AppArmor, але у 2007 році відокремився від власного відділу розробки AppArmor, а також використовує SELinux з 2008 року. Як результат, розробка AppArmor значно уповільнилася, поки Джон Йохансен не дав йому нового імпульсу на початку року і нарешті не проштовхнув його в офіційне ядро. Раніше Йохансен працював у Novell і в даний час відповідає за інтеграцію AppArmor в Ubuntu в Canonical.

Fanotify, який вийшов з TALPA, потребував численних спроб і за кілька років до того, як Торвальдс інтегрував його (включаючи 1, 2, 3). Він базується на Fsnotify, інтегрованому в 2.6.31, і пропонує точки входу, за допомогою яких сканери вірусів, наприклад, можуть підключатись для перевірки файлів під час доступу до шкідливих програм до доставки їх вмісту ("сканування при доступі"). Кілька статей LWN.net (у тому числі 1, 2, 3) містять деяку довідкову інформацію про те, як працює Fanotify, а також проблеми попередніх версій Fanotify.

[Оновлення 14 жовтня 2010 р., 9:30] Лише за кілька днів до завершення роботи Linux 2.6.36 розробники тимчасово деактивували інтерфейси користувацького простору Fanotify, щоб мати можливість виправити деякі недоліки, деякі з яких також впливають на ABI (1, 2, 3) - це означає, що Fanotify поки що не можна використовувати. Налагодження та повторна активація інтерфейсів простору користувача заплановані для ядра 2.6.37; Досі незрозуміло, чи ці патчі, можливо, також потраплять в одне зі стабільних ядер серії 2.6.36. [/Оновлення]

Управління пам’яттю та потоками

Розробники ядра суттєво змінили і значною мірою переписали вбивцю Out of Memory (OOM), яка вбиває процеси, коли недостатньо пам'яті, щоб система могла продовжувати працювати (1, 2, 3). Через ці зміни, точне коригування OOM застосовується через/proc /

/ oom_adj тепер "застарілий" і повинен зникнути в серпні 2012 року. LWN.net надає більше довідкової інформації про зміни до OOM у статті "Ще один переписувач вбивці OOM".

Хакери ядра також інтегрували "Конкурсовані керовані робочі черги", які оптимізують обробку потоків ядра (включаючи 1, документацію). Як результат, ядро повинно використовувати ресурси ефективніше, масштабувати їх краще і проходити з меншою кількістю потоків у багатьох системах - користувачі також помітять останнє, оскільки це скорочує список потоків ядра, виданих ps -A. Розробник надає додаткові переваги та причини змін у детальній пошті на свої патчі та як частину запиту Git-Pull; LWN.net написав статтю про "Управлінські робочі завдання, що керуються збігом" восени минулого року.

[віртуалізація розбиття сторінок, Kbuild]

Архітектурний код

Список архітектур процесорів, що підтримуються ядром, знову зростає з 2.6.36 і тепер також включає 32-розрядні процесори TILEPro та TILE64 (включаючи 1, 2, 3), розроблені Tilera. Вони є подібними до MIPS процесорами VLIW з багатьма ядрами, які взаємодіють між собою через мережу iMesh. Оскільки вони досить економічні, у серверній стійці можна розмістити більше 10 000 процесорних ядер. Підтримка процесорів Tegra від Nvidia, які базуються на архітектурі ARM (включаючи 1, 2, 3), надходить із середовища Android. Крім того, ядро зараз містить близько 90 відсотків драйверів для Ben NanoNote (включаючи 1, 2, 3, 4, 5, 6, 7, 8) - кишеньковий комп'ютер з відкритою апаратною платформою, який також доступний в Європі з весни доступний.

Супровідник KVM Avi Kivity пише у своєму запиті Git-Pull, що у KVM для 2.6.36 немає основних нових можливостей. Однак він вказує на деякі оптимізації продуктивності та згадує підтримку команд процесора Xsave (1, 2) та AVX (Intel Advanced Vector Extension) в гостьових системах.

Запити Git-Pull від Джеремі Фіцхардінге та Конрада Жешутека Вілка дають огляд змін до коду Xen. З виправленнями, зібраними першими, драйвери Paravirt тепер також можуть використовуватися в повністю віртуалізованих доменах ("pv-on-hvm"); Інші зміни означають, що Linux як паравіртуалізована гостьова система може отримати доступ до пристроїв PCI за допомогою свого роду віртуального IOMMU, який надає хост (Dom0) (включаючи 1). Деякі зміни також закладають основи, на яких повинен базуватися код для роботи ядра Linux як "початкового домену" - свого роду знезаражена підтримка Dom0. Цей код зараз обговорюється в LKML і може перейти до основної галузі розвитку Linux в одній з наступних версій.

Худий

Код Kbuild тепер пропонує чотири нові цілі:

"oldnoconfig" замінює "loose_nonint_oldconfig" і встановлює всі параметри конфігурації у файлі конфігурації ядра ".config" на "no", які раніше не були встановлені.
"listnewconfig" замінює "nonint_oldconfig" і перелічує всі параметри, які ще не встановлені в ".config".
"alldefconfig" створює ".config", в якому всі опції отримують параметри, визначені файлами Kconfig за замовчуванням.
"savedefconfig" пише файл конфігурації під назвою "defconfig", в якому перераховані лише ті параметри, які відрізняються від стандартних налаштувань файлів Kconfig.

За допомогою останнього make target розробники створили десятки стандартних конфігураційних файлів для різних системних та процесорних архітектур, що підтримуються ядром Linux, які замінюють попередні стандартні конфігураційні файли. Оскільки останній також раніше містив записи для всіх параметрів, які файли kconfig ядра вказані як стандартні, відповідний коміт становить майже 6 МБ і видаляє понад двісті тисяч рядків у джерелах ядра.

Адміністратори Itanium (IA64) та Power підтримки раніше впорядковували свої конфігураційні файли таким чином (1, 2). Всі ці зміни є основною причиною того, чому вихідний код 2.6.36 повинен бути трохи меншим за його безпосереднього попередника - це надзвичайно незвично, оскільки за останні роки ядро виросло на кілька сотень тисяч рядків з кожною новою версією.

Дієта для стандартних файлів конфігурації вже почалася з 2.6.35, коли розробники ядра зробили файли для систем ARM більш стрункими. Все це нічого не змінює для користувача, оскільки, як і раніше, "make defconfig" створює базовий конфігураційний файл для вашої власної системи.

[розбиття сторінок різне, маленькі перлини]

різноманітні

Хакери ядра ще більше скоротили використання Big Kernel Lock (BKL) в інфраструктурному коді та численних драйверах - у тому числі в підсистемі TTY, що викликало труднощі навіть у деяких найдосвідченіших хакерів ядра. Таким чином, розробники наближаються до мети ядра, що працює на стандартних системах без цього громіздкого механізму блокування, що погіршує масштабованість та продуктивність системи.
Код x86 тепер підтримує повідомлення про обмеження потужності від процесорів Intel Sandy Bridge, які очікуються на початку наступного року (1, 2, 3). Новий драйвер Hwmonitor pkgtemp базується на ньому і може зчитувати температуру процесора (1, документація)
У певних ситуаціях планувальник процесів зменшує конкуренцію між потоками ядра, які хочуть отримати ексклюзивний контроль над зайнятим ресурсом. Це дозволяє активному процесу працювати безперешкодно, що в деяких випадках значно збільшує пропускну здатність даних (коміт, стаття LWN.net).
Як і у своїх попередників, 2.6.36 також вносить численні зміни в код налагодження, моніторингу продуктивності та трасування. Наприклад, хакери ядра видалили плагін Ftrace kmemtrace, оскільки функції тепер можуть виконуватися з використанням подій трасування типу "kmem" та "perf kmem". Як вже було описано в першій частині серії "Що приносить 2.6.36", ядро в системах з підтримкою Intel KMS тепер пропонує оболонку налагоджувача KDB для аналізу причини збою сервера X коли перехід на текстову консоль перестає бути можливим, а послідовна консоль не налаштована.
Майже через місяць після закінчення вікна злиття хакери ядра внесли зміни до планувальника процесів, завдяки яким планувальник повинен скоротити максимальний час очікування, особливо в настільних системах, коли інші процеси вимагають паралельно часу процесора - це обіцяє краще Швидкість відповіді, яка повинна змусити систему почуватись швидше. Обговорення, що передує зміні, та коментар коміту пояснюють передумови та надають виміряні значення, згідно з якими максимальна затримка в тестовому сценарії майже вдвічі зменшилася.
З 2.6.36 хакери ядра хочуть усунути проблему, через яку системи з 2.6.35 та деякі попередні версії ядра відчували себе надзвичайно повільно за певних умов або припиняли відповідати часом, тоді як ядро передавало більші обсяги даних на повільний носій (наприклад, флешку) писав (у тому числі 1).
Покращення безпеки Tomoyo тепер пропонує "Інтерактивний режим примусу", за допомогою якого адміністратори можуть вирішити, чи ігнорувати порушення політики. Відео на YouTube ілюструє, як це працює.
Стефані Сейболд змінила API Kfifo, який вже був суттєво перероблений у 2.6.32, для покращення продуктивності та забезпечення кращого API (включаючи 1, 2). Старі виклики API все ще підтримуються, нові можливості пояснюються кількома прикладами.
Coccinelle тепер можна викликати через make target "coccicheck" - програму для семантичного аналізу коду, яка може полегшити програмістів від роботи при рефакторингу коду. Детально про можливості наводиться документація до ядра та стаття, опублікована на LWN.net навесні минулого року.

Маленькі перлини

Багато незначних, але далеко не незначних змін можна знайти в наступному списку з англійськими заголовками комітів відповідної зміни. Як і багато посилань у попередньому тексті, записи посилаються на веб-інтерфейс гілки Git, що підтримується Лінусом Торвальдсом, із "офіційними" джерелами ядра на Kernel.org. Коментар коміту, що відображається за цими посиланнями, та виправлення, випущене під ним, надають багато додаткової інформації про відповідні зміни.

Перед кожним посиланням є кілька літер і цифр у квадратних дужках. "C" позначає патчі із змінами у файлах Kconfig, які містять тексти довідки та параметри конфігурації, які відображаються під час конфігурації ядра за допомогою "make menuconfig", "make xconfig" та подібних інструментів. "D" означає виправлення, які змінюють документацію, яка знаходиться у гілці ядра в розділі Документація /. "N" означає зміни, які створюють новий файл. Цифра дає приблизне враження про розмір виправлення: «1» означає зміни розміром від 10 до 20 Кбайт, включаючи коментарі, «2» - для розмірів від 20 до 30 Кбайт; Зміни без числа менше 10 КБ, тоді як виправлення з "9" - 90 КБ або більше.

Налагодження, моніторинг продуктивності та код відстеження