ROSA Forum

В репозитории http://abf-downloads.rosalinux.ru/kerne ... osa2014.1/ на днях отправились новые версии ядра, 4.4.16 и 4.6.5.

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

1. Для 32-битных систем ядра nrj-desktop и nrj-laptop идут теперь c поддержкой PAE. Такие ядра и будут использоваться в установочных образах ROSA по умолчанию после ROSA R8.

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

2. В ядре теперь поддерживается SELinux вместо TOMOYO. При запуске системы SELinux по умолчанию выключен (disabled), чтобы не мешал. Но можно включить, если при загрузке в списке параметров ядра задать selinux=1.

Для домашнего использования это всё неважно, но для каких-то корпоративных пользователей может пригодиться. Правда, это только первый шаг: нужно ещё, чтобы в различных user-space компонентах SELinux поддерживался и .т.п. То уже не по моей части

3. Для энтузиастов: теперь стало гораздо проще собирать свои варианты ядра, пробовать те или иные исправления, экспериментировать с настройками и т.п.

До сих пор файлы с настройками ядра и патчи к ядру, у нас хранились в отдельном проекте на ABF, дорабатывались и применялись спец. скриптами оттуда же. Это оказалось не очень удобно: чтобы добавить даже минимальный патч, требовалось не запутаться во всём этом.

Теперь всё более прямолинейно: все соотв. файлы лежат в том же проекте, что и spec-файл для сборки RPM-пакетов с ядром, см., например, проект для ядра 4.6: https://abf.io/kernels_stable/kernel-4.6

Config-файлы для ядра просто "склеиваются" из частей при сборке пакетов: например, для nrj-desktop на 64-битных системах берётся kernel-x86_64.config (т.е. общая часть) и kernel-nrj-desktop-x86_64.config (добавка для nrj-desktop). Для nrj-laptop - kernel-x86_64.config и kernel-nrj-laptop-x86_64.config.

Патчи теперь тоже применяются точно так же, как и при сборке других RPM-пакетов, не нужно разбираться в доп. скриптах.

Так что - хотите что-то изменить в ядре, с чем-то поэкспериментировать? Скопируйте проект https://abf.io/kernels_stable/kernel-4.6, отредактируйте config-файлы для ядра по вкусу, добавьте или удалите патчи - и можно запускать сборку RPM-пакетов.

Кстати. Вот пробные образы с ядром 4.4.16, которое было собрано уже по новой схеме:
https://abf.io/platforms/rosa2014.1/pro ... ists/15790

Пока эти нововведения касаются только ядер 4.4.x и 4.6.x. Если они окажутся удачными, распространим это всё и на другие ветки ядра.

Спасибо за проделанную работу.

Что касаемо PAE, то на 32-хбитных процессорах Intel Atom (нетбуки) и еще кучи старых процессорах на сокетах 472 и 478 оно реально вредно.
Последний раз, когда пробовал на Samsung N127 запустить ядро с PAE (правда тогда еще OpenSUE там была), бессистемно получал Kernel Panic

Yamah писал(а):Спасибо за проделанную работу.

Что касаемо PAE, то на 32-хбитных процессорах Intel Atom (нетбуки) и еще кучи старых процессорах на сокетах 472 и 478 оно реально вредно.
Последний раз, когда пробовал на Samsung N127 запустить ядро с PAE (правда тогда еще OpenSUE там была), бессистемно получал Kernel Panic

Да, бывали такие случаи на относительно старом железе. Впрочем, на тех Атомах, до которых я в этом году смог добраться (EeePC 10xx, 12xx выпуска 2009-2012 г.), таких проблем я уже не наблюдал.

Посмотрим, как сейчас у пользователей пойдёт.

Хорошо, что spec файл сократился в объёме почти вдвое.

По поводу патчей. Я использовал стандартный для rpmbuild способ их включения для того, что бы была возможность посмотреть изменения ядра через веб-интерфейс сборочной фабрики. С этой точки зрения, было бы проще воспринимать проект визуально, когда файлы в нём упорядочены по типу. Локально это не сложно обеспечить сортировкой по расширению, но для ABF рассчитывать на такое пока не приходится. Поэтому, может быть имеет смысл именовать все патчи начиная с цифр, подобно первым трём для BFQ?

По поводу "склейки конфигов". Perl скрипт позволяет изменить стандартные значения опций. Как с этой возможностью в новом варианте? Как я понимаю, в результирующем файле опция будет встречаться дважды, и либо первая, либо последняя имеет приоритет. Конечно, можно и нужно проверить, но хотелось бы увидеть официальное разъяснение, наверное лучше и в шапке темы.

Такой момент:

Код: Выделить всё

%smake -C tools/perf -s IS_X86_64=%{perf_is_x64} HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all

В ядре 4.7.4 tools/perf/config/Makefile вижу проверки IS_64_BIT. IS_X86_64 не нашел. Переименовали?

Пробовал на 64х битной машине собирать локально 32х битную версию.
Казалось бы очевидное:

Код: Выделить всё

rpmbuild -ba --target i586 -D '_without_nrj_desktop 1' kernel-4.7-test/kernel.spec

привело к

Код: Выделить всё

    Файл не найден: /home/st/rpmbuild/BUILDROOT/kernel-r4-4.7.4-1-rosa2014.1.i586-buildroot/usr/lib/traceevent
    Файл не найден: /home/st/rpmbuild/BUILDROOT/kernel-r4-4.7.4-1-rosa2014.1.i586-buildroot/usr/lib/traceevent/plugins
    Файл не найден: /home/st/rpmbuild/BUILDROOT/kernel-r4-4.7.4-1-rosa2014.1.i586-buildroot/usr/lib/libperf-gtk.so
    Файл не найден: /home/st/rpmbuild/BUILDROOT/kernel-r4-4.7.4-1-rosa2014.1.i586-buildroot/usr/lib/traceevent/plugins/*
    Обнаружен(ы) установленный(е) (но не упакованный(е)) файл(ы):
        /usr/bin/perf-read-vdso32
        /usr/lib64/libperf-gtk.so
        /usr/lib64/traceevent/plugins/plugin_cfg80211.so
        /usr/lib64/traceevent/plugins/plugin_function.so
        /usr/lib64/traceevent/plugins/plugin_hrtimer.so
        /usr/lib64/traceevent/plugins/plugin_jbd2.so
        /usr/lib64/traceevent/plugins/plugin_kmem.so
        /usr/lib64/traceevent/plugins/plugin_kvm.so
        /usr/lib64/traceevent/plugins/plugin_mac80211.so
        /usr/lib64/traceevent/plugins/plugin_sched_switch.so
        /usr/lib64/traceevent/plugins/plugin_scsi.so
        /usr/lib64/traceevent/plugins/plugin_xen.so

после чтения Makefile.perf

Код: Выделить всё

# Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for cross-builds.

вышеприведённое недоразумение исчезает, но для линковки требуются 32х битные версии библиотек.

На ABF указанная ситуация исключена, так что проще собирать там. Локально проверить можно и "родную" архитектуру.

Что-то я пропустил эти комментарии раньше. Поздновато, конечно, но всё же.

trs писал(а):Хорошо, что spec файл сократился в объёме почти вдвое.

По поводу патчей. Я использовал стандартный для rpmbuild способ их включения для того, что бы была возможность посмотреть изменения ядра через веб-интерфейс сборочной фабрики. С этой точки зрения, было бы проще воспринимать проект визуально, когда файлы в нём упорядочены по типу. Локально это не сложно обеспечить сортировкой по расширению, но для ABF рассчитывать на такое пока не приходится. Поэтому, может быть имеет смысл именовать все патчи начиная с цифр, подобно первым трём для BFQ?

Не всегда удобно, т.к. иногда порядок патчей приходится менять, какие-то удалять и пр. Поэтому пока оставил как есть.

trs писал(а): По поводу "склейки конфигов". Perl скрипт позволяет изменить стандартные значения опций. Как с этой возможностью в новом варианте? Как я понимаю, в результирующем файле опция будет встречаться дважды, и либо первая, либо последняя имеет приоритет. Конечно, можно и нужно проверить, но хотелось бы увидеть официальное разъяснение, наверное лучше и в шапке темы.

На практике большая часть возможностей тех скриптов теперь не нужна. Основные варианты сейчас:
- desktop VS laptop,
- с debug info VS без debug info
- c memory sanitization и без.

Это всё делается частью склейкой конфигов, частью - несложными заменами из spec-файла.

Если нужно поменять значения каких-то параметров, надёжнее всего сделать это явно в соотв. *.config файле. Тогда не будет и проблем с дублирующимися параметрами.

trs писал(а):Такой момент:
Код: Выделить всё
%smake -C tools/perf -s IS_X86_64=%{perf_is_x64} HAVE_CPLUS_DEMANGLE=1 prefix=%{_prefix} all
В ядре 4.7.4 tools/perf/config/Makefile вижу проверки IS_64_BIT. IS_X86_64 не нашел. Переименовали?

Возможно, IS_X86_64 уже не нужен. Этот хак требовался какое-то время назад, когда perf сам неправильно определял, как ему собираться. С тех пор и не трогали.

trs писал(а):На ABF указанная ситуация исключена, так что проще собирать там. Локально проверить можно и "родную" архитектуру.

Да, надёжнее собирать именно на "родной" архитектуре.

ROSA Forum

Изменения в ядре ROSA Fresh

Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh

Re: Изменения в ядре ROSA Fresh