Итак вполне типичная задача - я строю десктопную gentoo. Меня интересует какие же ядра имеются в gentoo:
ls -1 /usr/portage/sys-kernel | grep sources
cell-sources
ck-sources
gentoo-sources
git-sources
hardened-sources
mips-sources
openvz-sources
pf-sources
rsbac-sources
rt-sources
tuxonice-sources
vanilla-sources
vserver-sources
xbox-sources
zen-sources
Если с vanilla-sources все понятно то git-sources это тоже самое но намного чаще что само по себе иногда намного лучше.
Внимание вопрос для особо внимательных и любопытных - почему git-sources не использует git? Если вы правильно ответили на первый вопрос то вот вам второй - не было бы идеологически более правильным вместо git-sources делать к примеру
vanilla-sources-{$PV}-`date +"%Y%m%d"`
?
Далее специфические ядра под особое железо это: cell-sources, mips-sources, xbox-sources.
Интересны только узкому кругу обладателей такого железа.
Ядра с патчами усиленной защиты: hardened-sources, rsbac-sources.
Десктоп параноиков не рассматриваем. У истинных параноиков не должно
быть десктопа по причинам безопасности.
Ядра с патчами под специфичные и далеко не десктопные задачи: openvz-sources, rt-sources, vserver-sources.
Почему бы не pf-sources
в котором:
ck,
BFQ,
TuxOnIce и
uksm?
Буду краток - Википедия
как всегда врет о том, что
Every user has work they need to do. The goal of Gentoo is to design
tools and systems that allow a user to do that work as pleasantly and
efficiently as possible, as they see fit. Our tools should be a joy to
use, and should help the user to appreciate the richness of the Linux
and free software community, and the flexibility of free software.
This is only possible when the tool is designed to reflect and
transmit the will of the user, and leave the possibilities open as to
the final form of the raw materials (the source code.) If the tool
forces the user to do things a particular way, then the tool is
working against, rather than for, the user. We have all experienced
situations where tools seem to be imposing their respective wills on
us. This is backwards, and contrary to the Gentoo philosophy.Put another way, the Gentoo philosophy is to create better tools. When
a tool is doing its job perfectly, you might not even be very aware of
its presence, because it does not interfere and make its presence
known, nor does it force you to interact with it when you don’t want
it to. The tool serves the user rather than the user serving the tool.The goal of Gentoo is to strive to create near-ideal tools. Tools that
can accommodate the needs of many different users all with divergent
goals. Don’t you love it when you find a tool that does exactly what
you want to do? Doesn’t it feel great? Our mission is to give that
sensation to as many people as possible.
В pf-sources выбор патчей сделан за ВАС, нельзя изменить их набор и в довершение ко
всему все идет ОДНИМ ПАТЧЕМ. Ваше право не соглашаться с филосифией gentoo. Но ваш внутренний параноик иногда подсказывает правильные ответы. Почему все идет одним патчем? Почему все сделано для того чтобы было как можно труднее разобраться в том какие именно исправления внесены и где?
Так же поступает red-hat со своим ядром. Но, во первых, из организаций и судя по вкладу в разработку red-hat является одним из основных разработчиков ядра linux. И во вторых делает он так для борьбы с oracle.
А с кем ведет борьбу pf-sources?
zen-sources - R.I.P ? если нет то поправьте меня. И лично для меня самое ценное в
zen-sources был патчь на цветной printk.
А вот все остальное в sys-kernel, за исключением вышеперечисленного, это все те же vanilla-sources и, как правило, один реже несколько, сторонних патча по тем или иным причинам не принятых в основное ядро. Итого gentoo предлагает ядер для типичного десктопа выбор из:
ck-sources - патчи
ck
gentoo-sources - патчи gentoo (которых под 3.6.6 целых ДВА)
Лично меня печалила такая ситуация. Мне нужно гораздо больше. Для начала хотя бы ck-sources, gentoo-sources и tuxonice-sources в одном “флаконе” и желательно чтобы каждый набор патчей управлялся своим USE флагом. Что немаловажно для возможности их проверки и возможной дальнейшей доработки я хотел видеть оригинальные патчи, а не
один патчь как в случае pf-sources.
Согласно Applying Patches To The Linux Kernel и здравому смыслу понятно что если патчей более одного то безусловно и накладывать их можно в разной последовательности. Т.е. последовательность наложения патчей тоже обязана иметь некие настройки.
Исходя из того же здравого смысла ясно что бывают и конфликтующие патчи.
В общем случае обезопасить себя от конфликтов при наложении патча можно так:
patch -p1 --dry-run < PATCH_FILE && patch -p1 < PATCH_FILE
Большую работу над исправлением разнообразных ошибок в ядре linux проделывают и основные дистрибутивы: fedora, SuSE, mandriva/mageia однако зачастую патчи принимаются в ядро с опозданием. Поэтому я хотел бы иметь эти исправления как можно раньше.
Если взглянуть повнимательнее на содержимое sys-kernel то станет ясно что ничего удовлетворяющего моим потребностям там нет. А если чего то нет - приходится делать это самому.
На данный момент sys-kernel/geek-sources-3.6.6
поддерживает:
USE флаг
Some feature
Аналог в
sys-kernel
aufs
bfq
Budget Fair Queueing Budget I/O
Scheduler
branding
Enable Gentoo specific branding
нет
ck
Enable Con Kolivas’ high performance
patchset
sys-kernel/ck-sources,
sys-kernel/pf-sources
debian
нет
deblob
Remove binary blobs from kernel sources to provide libre license
compliance
есть во всех ядрах
fedora
нет
genpatches
grsecurity
hardened-sources,
rsbac-sources
ice
sys-kernel/tuxonice-sources,
sys-kernel/pf-sources
mageia
нет
reiser4
нет
rt
Use Ingo Molnar’s realtime preempt
patches
suse
нет
uksm
Use Ultra Kernel Samepage Merging
patches
vserver
VServer provides virtualization for GNU/Linux
systems
zfs
The native Linux kernel port of the ZFS
filesystem
Порядок наложения патчей управляется при помощи переменной
GEEKSOURCES_PATCHING_ORDER. К примеру если нужно чтобы все патчи
накладывались в алфавитном порядке:
:::BashLexer
echo ‘GEEKSOURCES_PATCHING_ORDER=”aufs bfq bld branding ck debian
fedora genpatches grsecurity ice imq mageia pardus pld reiser4 rt suse
uksm vserver zfs”’ > /etc/portage/kernel.conf
[/sourcecode]
По умолчанию(при отсутствии файла /etc/portage/kernel.conf)
GEEKSOURCES_PATCHING_ORDER принимается:
:::BashLexer
GEEKSOURCES_PATCHING_ORDER=”vserver bfq ck genpatches grsecurity ice
imq reiser4 rt bld uksm aufs mageia fedora suse debian pardus pld zfs
branding”
[/sourcecode]
Все версии
sys-kernel/geek-sources
я тестирую, собираю и использую с
:::BashLexer
$ emerge sys-kernel/geek-sources -pv
These are the packages that would be merged, in order:
Calculating dependencies… done!
[ebuild R ] sys-kernel/geek-sources-3.6.6:3.6.6::init6 USE=”aufs bfq
branding ck debian fedora ice mageia suse uksm -deblob -genpatches
-grsecurity -reiser4 -rt -vserver -zfs” 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
[/sourcecode]
Aufs мне нужен вот собственно для этого Squashed Portage
Tree.
Поскольку я использую cryptsetup -> llvm2 -> ext4 то по мотивам Early
Userspace
Mounting
сделал свой собственный
initramfs.
А собираю все ядра я при помощи
install_kernel.
В дальнейшем я планирую доработать
kernel-geek.eclass
для того чтобы сборка ядра производилась при помощи portage.
Comments