Linux kernel on github

Linux kernel on github

Linux Kernel Utilities

Compile a kernel from source: compile_linux_kernel.sh

For use with Debian and derivatives (e.g. Ubuntu, LinuxMint, etc.)

Bash script that will scrape http://www.kernel.org for available kernels and present the user with a GUI for manually selecting options. This script will also check the downloaded archive against the PGP signature file.

Note: The user MUST save a configuration from the GUI even if defaults are used.
The configuration routine will pull the current machine’s configuration in to the utility as a base.

Download precompiled Ubuntu kernel: update_ubuntu_kernel.sh

Bash script that will scrape https://kernel.ubuntu.com for available precompiled kernels and present the user with a menu for selection. It is set to currently filter for kernels at v5. Both generic and lowlatency choices are provided.

This is intended explicitly for Ubuntu and derivatives like LinuxMint.

Remove all inactive kernels: remove_old_kernels.sh

Bash script that will purge ALL inactive kernels.

This may not be prudent for some as this will leave no default / backup safety kernel. The only kernel that will remain is the currently loaded version. It is highly recommended that a reboot be performed before executing this script.

Method 1: (Recommended) — Download and enable scripts wtih git

Method 2: DEB packages

Standard DEB installation packages are available from the Releases section.

Notes:

• Scripts are installed to /opt when using DEB packages.
• Scripts will prompt to update when necessary. To update, use: git pull .

To compile a kernel with manual version selection

To compile the latest kernel available

To compile a kernel from a local archive file

To compile the latest kernel automagically using a profile

Precompiled Ubuntu (and derivatives)

To download and install a precompiled Ubuntu kernel from kernel.ubuntu.com

To download and install the latest precompiled Ubuntu kernel from kernel.ubuntu.com

Removal of inactive kernels

To remove ALL inactive kernels (i.e. all kernels other than the currently loaded instance)

Do not run the scripts with sudo . They will prompt for elevated privileges if necessary.

The script will detect remote usage and execute QT or NCURSES accordingly.

Some older kernels (e.g. 3.x) require earlier versions of QT. If you are building v3.x kernels you should manually install QT4 before compiling. The script is set to install QT5 if missing.

Kernel Source Preservation

When installing a compiled kernel, links are created to the kernel source so that DKMS will function correctly. Therefore, you should take care not to delete the Build_xxxx folders after installation. If you compile a newer release and remove an older kernel using dpkg -r , it is then safe to delete the entire directory of the removed kernel version.

CI & Unit Testing

Internal: Gitlab & Gitlab CI
External: Github & Travis CI
BATS

• You can set RC_FILTER to control whether Release Candidates are offered as a choice.
• Enlarge your terminal window before executing the scripts to make sure proper formatting of available choices.
• Multicore thread compiling is set automatically to twice the amount of detected cores.
• Consider temporarily increasing grub menu timeouts and / or unhiding in case the new kernel is problematic.

CRISIS — cannot boot properly after new kernel is installed

If all else fails and a new kernel prevents you from booting you can:

Boot to a linux based LiveCD (e.g. GParted on a USB)

Mount the partition: sudo mount /dev/sdXY /mnt
where sdXY is likely your sda1

Mount some special partitions:
sudo mount —bind /dev /mnt/dev
sudo mount —bind /proc /mnt/proc
sudo mount —bind /sys /mnt/sys

Chroot into /mnt:
sudo chroot /mnt

Remove the kernel packages you just installed
dpkg -r yourRecentKernels

They must be removed in a non-dependency order, so just take your time.

dpkg —list | grep «ii[[:space:]][[:space:]]linux-[f,h,i,l]»
will help list your installs

Источник

Linux kernel on github

linux-tkg custom kernels

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This repository provides scripts to automatically download, patch and compile the Linux Kernel from the official Linux git repository, with a selection of patches aiming for better desktop/gaming experience. The provided patches can be enabled/disabled by editing the customization.cfg file and/or by following the interactive install script. You can also use your own patches (more information in customization.cfg file).

Non-pacman distros support can be considered experimental. You’re invited to report issues you might encounter with it.

In intel_pstate driver, frequency scaling aggressiveness has been changed with kernel 5.5 which results in stutters and poor performance in low/medium load scenarios (for higher power savings). As a workaround for our gaming needs, we are setting it to passive mode to make use of the acpi_cpufreq governor passthrough, keeping full support for turbo frequencies. It’s combined with our aggressive ondemand governor by default for good performance on most CPUs while keeping frequency scaling for power savings. In a typical low/medium load scenario (Core i7 9700k, playing Mario Galaxy on Dolphin emulator) intel_pstate in performance mode gives a stuttery 45-50 fps experience, while passive mode + aggressive ondemand offers a locked 60 fps.

Nvidia’s proprietary drivers might need to be patched if they don’t support your chosen kernel OOTB: Frogging-Family nvidia-all can do that automatically for you.

Note regarding kernels older than 5.9 on Arch Linux: since the switch to zstd compressed initramfs by default, you will face an invalid magic at start of compress error by default. You can workaround the issue by editing /etc/mkinitcpio.conf to uncomment the COMPRESSION=»lz4″ (for example, since that’s the best option after zstd) line and regenerating initramfs for all kernels with sudo mkinitpcio -P

Alternative CPU schedulers

CFS is the only CPU scheduler available in the «vanilla» kernel sources. Its current implementation doesn’t allow for injecting additional schedulers, and requires replacing it. Only one scheduler can be patched in at a time.

Alternative schedulers are available to you in linux-tkg:

• Project C / PDS & BMQ by Alfred Chen: blog, code repository
• MuQSS by Con Kolivas : blog, code repository
• CacULE by Hamad Marri: code repository
• Undead PDS: TkG’s port of the pre-Project C «PDS-mq» scheduler by Alfred Chen. While PDS-mq got dropped with kernel 5.1 in favor of its BMQ evolution/rework, it wasn’t on par with PDS-mq in gaming. «U» PDS still performs better in some cases than other schedulers, so it’s been kept undead.

These alternative schedulers can offer a better performance/latency ratio for gaming and desktop use. The availability of each scheduler depends on the chosen Kernel version: the script will display what’s available on a per-version basis.

• Memory management and swapping tweaks
• Scheduling tweaks
• CFS tweaks
• Using the «Cake» network queue management system
• Using vm.max_map_count=524288 by default
• Cherry-picked patches from Clear Linux’s patchset

The customization.cfg file offers many toggles for extra tweaks:

• Fsync , Futex2 and Fastsync+winesync support: can improve the performance in games, needs a patched wine like wine-tkg
• Graysky’s per-CPU-arch native optimizations: tunes the compiled code to to a specified CPU
• Compile with GCC or Clang with optional O2 / O3 and LTO (Clang only) optimizations.
  • Warning regarding DKMS modules and Clang: DKMS will default to using GCC, which will fail to build modules against a Clang-built kernel. This will — for example — break Nvidia drivers. Forcing DKMS to use Clang can be done but isn’t recommended.
• Using Modprobed-db’s database can reduce the compilation time and produce a smaller kernel which will only contain the modules listed in it. NOT recommended
  • Warning: make sure to read thoroughly about it first since it comes with caveats that can lead to an unbootable kernel.
• «Zenify» patchset using core blk, mm and scheduler tweaks from Zen
• Anbox support (See Anbox usage)
• ZFS FPU symbols ( .config file
• .

To apply your own patch files using the provided scripts, you will need to put them in a linux5y-tkg-userpatches folder — y needs to be changed with the kernel version the patch works on, e.g linux510-tkg-userpatches — at the same level as the PKGBUILD file, with the .mypatch extension. The script will by default ask if you want to apply them, one by one. The option _user_patches should be set to true in the customization.cfg file for this to work.

When enabling the anbox support option, the binder and ashmem modules are built-in. You don’t have to load them. However you’ll need to mount binderfs :

To make this persistent, you can create /etc/tmpfiles.d/anbox.conf with the following content :

After which you can add the following to your /etc/fstab :

Then, if needed, start the anbox service :

You can also enable the service for it to be auto-started on boot :

You’re set to run Anbox. If you prefer automatic setup you can install anbox-support from AUR which will take care of everything by itself.

The script will use a slightly modified Arch config from the linux-tkg-config folder, it can be changed through the _configfile variable in customization.cfg . The options selected at build-time are installed to /usr/share/doc/$pkgbase/customization.cfg , where $pkgbase is the package name.

DEB (Debian, Ubuntu and derivatives) and RPM (Fedora, SUSE and derivatives) based distributions

The interactive install.sh script will create, depending on the selected distro, .deb or .rpm packages, move them in the the subfolder DEBS or RPMS then prompts to install them with the distro’s package manager.

Uninstalling custom kernels installed through the script has to be done manually. install.sh can can help out with some useful information:

The script will use a slightly modified Arch config from the linux-tkg-config folder, it can be changed through the _configfile variable in customization.cfg .

If you have to restart the build for any reason, run ./xbps-src clean linux-tkg first.

The interactive install.sh script can be used to perform a «Generic» install by choosing Generic when prompted. It git clones the kernel tree in the linux-src-git folder, patches the code and edits a .config file in it. The commands to do are the following:

The script will compile the kernel then prompt before doing the following:

Notes:

• If you only want the script to patch the sources in linux-src-git , you can use ./install.sh config
• $ is a default naming scheme but can be customized with the variable _kernel_localversion in customization.cfg .
• _dracut_options is a variable that can be changed in customization.cfg .
• The script uses Arch’s .config file as a base. A custom one can be provided through _configfile in customization.cfg .
• The installed files will not be tracked by your package manager and uninstalling requires manual intervention. ./install.sh uninstall-help can help with useful information if your install procedure follows the Generic approach.

The interactive install.sh script supports Gentoo by following the same procedure as Generic , symlinks the sources folder in /usr/src/ to /usr/src/linux , then offers to do an emerge @module-rebuild for convenience

Notes:

• The script will prompt for using llvm-libunwind , it can only work with the llvm-libunwind USE flag in sys-devel/clang but it is experimental:
  • Manual intervention is needed on the net-fs/samba EBUILD, see here
  • The -unwind USE flag is needed in app-emulation/wine* EBUILDs

Источник

Почему GitHub не может хостить ядро Linux

Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.

Масштабирование в стиле GitHub

Git классный, потому что каждый может очень легко сделать форк, создать свою ветку и изменять код. И если в итоге у вас получится нечто стоящее, вы создаёте пулл-реквест для основного репозитория и его рассматривают, тестируют и осуществляют слияние. И GitHub классный, потому что он представил подходящий UI, чтобы эти сложные вещи было приятно и просто находить и изучать, так что новичкам гораздо легче войти в курс.

Но если проект в итоге стал чрезвычайно успешным и никакое количество тегов, меток, сортировки, ботов и автоматизации уже не способны справляться со всеми пулл-реквестами и проблемами в репозитории, то приходит время снова разделить проект на более управляемые части. Более важно, что с определённым размером и возрастом проекта разным частям понадобятся разные правила и процессы: у сверкающей новой экспериментальной библиотеки иная стабильность и критерии CI, чем у основного кода, а может у вас в наличии мусорный бак legacy с кучей исключённых плагинов, которые уже не поддерживаются, но их нельзя удалять. Так или иначе, придётся разделить огромный проект на подпроекты, каждый с собственным процессом и критерием слияния патчей и с собственным репозиторием, где работают свои пулл-реквесты и отслеживание проблем. Обычно нужно от нескольких десятков до нескольких сотен контрибуторов, работающих полный рабочий день, чтобы головная боль от проекта выросла до такой степени, что станет необходимо разделение на части.

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

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

• Ваше сообщество слишком фрагментируется. Большинство контрибуторов будут просто иметь дело с кодом и соответствующим репозиторием, куда они напрямую контрибутят, игнорируя всё остальное. Им-то классно, но так значительно снижается вероятность вовремя заметить дублирующиеся усилия и параллельные решения между разными плагинами и бибилотеками. И людям, которые хотят управлять всем сообществом в целом, придётся иметь дело с кучей репозиториев, которые или управляются через скрипт, или подмодули Git, или что-то ещё худшее. К тому же, они утонут в пулл-реквестах и проблемах, если на что-нибудь подпишутся. Любая тема (может, у вас общий инструментарий для сборки билдов или документация, или что угодно ещё), которая не вписывается идеально в разделённые репозитории, становится головной болью для мейнтейнеров.
• Даже если вы заметили необходимость рефакторинга и совместного использования кода, здесь возникает больше бюрократических препятствий: сначала нужно выпустить новую версию ключевой библиотеки, затем пройтись по всем плагинам и обновить их, и только потом, может быть, вы сможете удалить старый код в библиотеке совместного доступа. Но поскольку всё сильно разбросано вокруг, вы можете и забыть о последнем шаге.

Конечно, всё это требует не такой уж большой работы, и многие проекты отлично справляются с управлением. Но здесь всё равно требуется больше усилий, чем простой пулл-реквест в единый репозиторий. Очень простые операции рефакторинга (как простое совместное использование единственной новой функции) происходят реже, и за долгое время такие издержки накапливаются. За исключением тех случаев, когда вы по примеру node.js создаёте репозитории для каждой функции, а затем по сути меняете Git на npm в качестве системы управления исходным кодом, и это тоже кажется странным.

• Комбинаторный взрыв теоретически поддерживаемых разных версий, которые становятся де-факто неподдерживаемым. Пользователям приходится осуществлять интеграционное тестирование. А в проекте всё сводится к одобренным («благословенным») сочетаниям версий, или по крайней мере такое декларируется де-факто, поскольку разработчики просто закрывают сообщения о багах словами «пожалуйста, сначала обновите все модули». И снова, это означает, что у вас фактически монорепозиторий, разве что не на Git. Ну, только если вы используете подмодули, и я не уверен, что это считается Git.
• Болезненная реорганизация при разделении общих проектов на подпроекты, поскольку вам нужно реорганизовать репозитории Git и то, как они разделяются. В едином репозитории смена мейнтейнера сводится к простому обновлению файлов OWNER или MAINTAINERS, а если ваши боты в порядке, то новые мейнтейнеры получат теги автоматически. Но если для вас масштабирование означат разделение репозиториев на разрозненные наборы, то любая реорганизация будет настолько же болезненна, как и первый шаг от единственного репозитория к группе разделённых репозиториев. Это означает, что ваш проект слишком надолго застрянет на плохой организационной структуре.

Интерлюдия: зачем существуют пулл-реквесты

Ядро Linux — один из нескольких известных мне проектов, который не разделён таким образом. Прежде чем мы рассмотрим, как он работает (ядро — это гигантский проект и он просто не может работать без некоторой структуры подпроектов), мне кажется, интересно посмотреть, зачем в Git нужны пулл-реквесты. На GitHub это единственный способ разработчикам внести предложенные патчи в общий код. Но изменения в ядре приходят как патчи в почтовом списке рассылки, даже через долгое время после внедрения и широкого использования Git.

Но уже первая версия Git поддерживала пулл-реквесты. Аудиторией этих первых, достаточно сырых, релизов были мейнтейнеры ядра, Git написали для решения мейнтейнерских проблем Линуса. Очевидно, Git был нужен и полезен, но не для обработки изменений от отдельных разработчиков: даже сегодня, а тем более тогда, пулл-реквесты использовались для обработки изменений целой подсистемы, синхронизации отрефакторенного кода или схожих сквозных изменений между различными подпроектами. Как пример, сетевой пулл-реквест 4.12 от Дэйва Миллера, представленный Линусом, содержит более 2000 коммитов от 600 разработчиков и кучу слияний для пулл-реквестов от подчинённых мейнтейнеров. Но почти все патчи сами по себе представлены мейнтейнерами и выбраны из почтовых списков рассылки, а не самими авторами. Такова особенность разработки ядра, что авторы в основном не коммитят патчи в общие репозитории — и вот почему Git отдельно учитывает автора патча и автора коммита.

Инновацией и улучшением в GitHub было использование пулл-реквестов для всего подряд, вплоть до отдельных патчей. Но не для этого пулл-реквесты изначально создавались.

Масштабирование способом ядра Linux

На первый взгляд, ядро выглядит как единый репозиторий, где всё в одном месте в репозитории у Линуса. Но это далеко не так:

• Почти никто не использует основной репозиторий Линуса Торвальдса. Если у них и работает что-то из апстрима, то обычно это одно из стабильных ядер. Но намного более вероятно, что у них ядро со своего дистрибутива, где обычно есть дополнительные патчи и бэкпорты, и оно даже не хостится на kernel.org, это совершенно другая организация. Или у них ядро от своего аппаратного вендора (для SoC и почти для всего, связанного с Android), которое часто значительно отличается от всего, что хостится в одном из «основных» репозиториев.
• Никто (кроме самого Линуса) не разрабатывает ничего для репозитория Линуса. У каждой подсистемы, а часто даже у крупных драйверов, есть собственные репозитории Git, с собственными списками почтовой рассылки для отслеживания патчей и обсуждения проблем полностью изолированно от всех остальных.
• Работа между подсистемами производится поверх дерева интеграции linux-next, которое содержит несколько сотен веток Git из примерно такого же количества репозиториев Git.
• Всё это сумасшествие управляется через файл MAINTAINERS и скрипт get_maintainers.pl, который для каждого данного сниппета кода может сказать, кто мейнтейнер, кто должен проверить код, где находится правильный репозиторий Git, какие использовать списки рассылки, как и где сообщать о багах. Информация основана не просто на расположении файла. Также производится анализ шаблонов кода для проверки, что кросс-подсистемные темы вроде обслуживания device-tree или иерархии kobject hierarchy обрабатываются правильными экспертами.

На первый взгляд это выглядит просто как изощрённый способ заполнить у каждого дисковое пространство кучей ерунды, которая ему не интересна, но есть и много сопутствующих незначительных преимуществ, которые накладываются друг на друга:

• Совершенно легко провести реорганизацию, выделяя вещи в подпроект — просто обновите файл MAINTAINERS, и готово. Остальное немного сложнее, чем должно быть, потому что вам может понадобиться создать новый репозиторий, новые списки рассылки и новую bugzilla. Это просто проблема UI, которую GitHub элегантно решил классной маленькой кнопкой fork.
• Очень, очень просто перевести обсуждение пулл-реквестов и проблем между подпроектами, вы просто изменяете поле Cc: в своём ответе. Также намного проще координировать работу между подсистемами, поскольку один пулл-реквест можно направить в несколько подпроектов, при этом ведётся только одно общее обсуждение (поскольку теги Msg-Ids: в тредах списка рассылки одинаковы для всех), хотя сами письма архивируются в куче разных архивов списков рассылок, проходят через разные списки рассылки и лежат в тысячах разных почтовых ящиков. Простое обсуждение тем и кода между подпроектами позволяет избежать фрагментации и так легче заметить, где будет полезно использование общего кода и рефакторинг.
• Работа между подсистемами не нуждается в каком-то танце с релизами. Вы просто изменяете код, который весь у вас в едином репозитории. Заметьте, что это намного эффективнее, чем возможно в раздельных репозиториях. В случае действительно агрессивного рефакторинга можно просто разделить работу между несколькими релизами, например, когда есть так много пользователей, что вы можете просто изменить их всех сразу, не вызывая слишком больших проблем с координацией.

Огромное преимущество того, что рефакторинг и обмен кодом стал проще — не нужно тащить с собой кучу легаси-мусора. Это детально объясняется в документе об отсутствии бреда со стабильными API.

Ничто не мешает вам создавать собственные экспериментальные дополнения, что является одним из ключевых преимуществ системы с множеством репозиториев. Добавили свой код в свой форк и оставили его там — никто никогда не заставит вас запушить код обратно или запушить его в один общий репозиторий или даже передать в основную организацию, просто потому что нет центральных репозиториев. Это действительно хорошо работает, может и слишком хорошо, свидетельством чему миллионы строк кода вне веток в различных репозиториях аппаратных вендоров Android.

В общем, думаю, это гораздо более мощная модель, потому что вы всегда можете откатиться и делать всё также, как с многочисленными разъединёнными репозиториями. Чёрт, есть даже драйверы ядра, которые находятся в своём собственном репозитории, отдельном от основного ядра, как проприетарный драйвер Nvidia. Ну, это просто как клей исходного кода вокруг блоба, но поскольку он может не содержать никаких частей ядра по юридическим причинам, это прекрасный пример.

Это выглядит как фильм ужасов о монорепозитории!

На первый взгляд ядро Linux выглядит как монорепозиторий, потому что в нём есть всё. И многие знают по собственному опыту, что монорепозитории доставлют много проблем, потому что с определённого размера они просто не могут масштабироваться.

Но если посмотреть ближе, такая модель очень, очень далека от единого репозитория Git. Одна только upstream-подсистема и репозитории драйверов уже дают вам несколько сотен. Если посмотреть на всю экосистему целиком, включая аппаратных вендоров, дистрибутивы, другие ОС на базе Linux и отдельные продукты, вы легко насчитаете несколько тысяч основных репозиториев и ещё много-много дополнительных. И это без учёта репозиториев Git чисто для личного использования отдельными разработчиками.

Ключевое отличие в том, что в Linux единая файловая иерархия как общее пространство имён для всего, но очень много различных репозиториев для всевозможных нужд и проектов. Это монодерево с многочисленными репозиториями, а не монорепозиторий.

Примеры, пожалуйста!

Прежде чем я начну объяснять, почему GitHub не способен в данный момент обеспечить такой рабочий процесс, по крайней мере, если вы хотите сохранить преимущества GitHub UI и интеграции, нужно посмотреть на некоторые примеры, как это работает на практике. Если вкратце, то всё делается через пулл-реквесты Git между мейнтейнерами.

Простой случай — это прохождение изменений через иерархию мейнтейнеров, пока они в конце концов не осядут в дереве там, где нужно. Это легко, потому что пулл-реквест всегда идёт из одного репозитория в другой, так что его можно провести с нынешним GitHub UI.

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

Слияние отличается от рассмотрения патча. Здесь уже выбирается одна из подсистем как основная, она получает все пулл-реквесты, а все остальные мейнтейнеры соглашаются с таким вариантом слияния. Обычно выбирают ту подсистему, которую сильнее всего затрагивают изменения, но иногда выбирают ту, в которой уже идёт какая-то работа, которая конфликтует с пулл-реквестом. Иногда создают абсолютно новый репозиторий и команду мейнтейнеров. Это часто происходит для функциональности, которая распространяется на всё дерево и не очень аккуратно содержится в нескольких файлах и директориях в одном месте. Недавний пример — дерево отображений DMA, которое пытается объединить работу, до сих пор распределённую среди драйверов, мейнтейнеров платформы и групп поддержки архитектуры.

Но иногда есть многочисленные подсистемы, которые конфликтуют с набором изменений и которым всем нужно как-то решить нетривиальный конфликт слияния. В этом случае патчи не применяются напрямую (пулл-реквест Rebase на GitHub), а вместо этого используется пулл-реквест только с необходимыми патчами, на основании коммита, общего для всех подсистем — его вносят во все деревья подсистем. Такая общая база важна, чтобы избежать загрязнения дерева подсистем ненужными изменениями. Поскольку дальнейшие пуллы касаются только специфических тем, эти ветки обычно называют тематическими ветками.

В качестве примера могу привести поддержку audio-over-HDMI, в этот процесс я был вовлечён непосредственно. Она касается и графической подсистемы, и подсистемы звуковых драйверов. Одинаковые коммиты из одного и того же пулл-реквеста вошли в графический драйвер Intel, а также в звуковую подсистему.

Совершенно другой пример, что это не безумие — единственный сравнимый проект ОС в мире тоже выбрал монодерево с потоком коммитов примерно как в Linux. Я говорю о ребятах с таким гигантским деревом, что им даже пришлось написать полностью новую виртуальную файловую систему GVFS для его поддержки…

Дорогой GitHub

К сожалению, GitHub не обеспечивает поддержку такого рабочего процесса, по крайней мере, не нативно с GitHub UI. Конечно, это можно сделать просто с чистым инструментарием Git, но тогда вы возвращаетесь к патчам в списке рассылки и пулл-реквестам по почте, которые выполняются вручную. Я считаю, это единственная причина, почему сообщество разработчиков ядра ничего не выиграет от перехода на GitHub. Есть также небольшая проблема, что несколько ведущих мейнтейнеров настроены категорически против GitHub в целом, но это уже не технический вопрос. И дело не только в ядре Linux. Дело в том, что в принципе все гигантские проекты на GitHub имеют проблемы с масштабированием, потому что GitHub на самом деле не даёт им возможности масштабироваться на многочисленные репозитории, привязанные к монодереву.

Итак, у меня есть запрос только одной фичи на GitHub:

Пожалуйста, реализуйте пулл-реквесты и трекинг багов, охватывающие различные репозитории одного монодерева.

Простая идея, огромные последствия.

Репозитории и организации

Во-первых, нужно сделать возможными многочисленные форки того же репозитория в одной организации. Просто посмотрите на git.kernel.org, большинство их репозиториев не являются личными. И даже если вы поддерживаете разные организации, например, для разных подсистем, требование наличия организации для каждого репозитория — глупое и избыточное, оно без какой-либо необходимости до предела затрудняет доступ и управление пользователями. Например, в графической подсистеме у нас было бы по одному репозиторию для каждого тестового набора userspace, общая библиотека userspace и общий набор инструментов и скриптов, которые используются мейнтейнерами и разработчиками, это GitHub поддерживается. Но потом вы добавите общий репозиторий подсистемы, плюс репозиторий для ключевой функциональности подсистемы и дополнительные репозитории для каждого крупного драйвера. Это всё форки, которые GitHub не делает. И у каждого из этих репозиториев будет куча веток: по крайней мере, одна для работы над функциями, а другая для исправления багов в текущем релизе.

Объединение всех веток в репозиторий не предлагать, поскольку смысл раздела на репозитории в том, чтобы разделить также пулл-реквесты и баги.

Родственный вопрос: нужно иметь возможность устанавливать связи между форками постфактум. Для новых проектов, которые всегда были на GitHub, это не является проблемой. Но Linux сможет перемещать максимум одну подсистему за раз, и на GitHub уже есть масса репозиториев Linux, которые не являются правильными форками друг друга.

Пулл-реквесты

Пулл-реквесты нужно привязать к нескольким репозиториям одновременно, сохраняя единый общий поток обсуждения. Вы уже можете переназначить пулл-реквест на другую ветку репозитория, но не на несколько репозиториев одновременно. Переназначение пулл-реквестов действительно важно, поскольку новые участники проекта будут просто создавать пулл-реквесты к тому, что они считают основным репозиторием. Боты затем могут перетасовать их с учётом всех репозиториев, перечисленных в файле MAINTAINERS для того набора файлов и изменений, которые содержит репозиторий. Когда я беседовал с сотрудниками GitHub, то сначала предложил им реализовать это напрямую. Но думаю, здесь всё можно автоматизировать скриптами, так что лучше будет оставить это только для индивидуальных проектов, поскольку тут нет единого стандарта.

Тут ещё довольно мерзкая проблема UI, потому что список патчей может отличаться в зависимости от ветки, куда идёт пулл-реквест. Но это не всегда ошибка пользователя, ведь какой-то из репозиториев уже может применить какие-то патчи.

Кроме того, статус пулл-реквеста должен отличаться для каждого репозитория. Один мейнтейнер может закрыть его, не принимая, поскольку решили, что его примет другая подсистема, в то время как другой мейнтейнер может произвести слияние и закрыть вопрос. В другом дереве могут даже закрыть пулл-реквест как невалидный, поскольку он неприменим для старой версии или форка от вендора. Ещё веселее, пулл-реквест может пройти через слияние несколько раз, с разными коммитами в каждой подсистеме.

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

Статусы опять же должны быть отдельными, поскольку после появления багфикса в одном репозитории он не становится сразу доступен для всех остальных. Может даже потребуется портировать его на предыдущие версии ядер и дистрибутивов, а кто-то может решить, что баг не стоит того и закроет его как WONTFIX, даже если он помечен как успешно разрешённый в соответствующем репозитории подсистемы.

Источник

Читайте также:  Linux get name from pid