Linux kernel git repository

Ubuntu Wiki

KernelGitGuide

Git is the source code management tool used by the Linux kernel developer community. Ubuntu has adopted this tool for our own Linux kernel source code so that we can interact better with the community and the other kernel developers.

Installing GIT

To use git you must have the git package installed on your system, which you can install like this:

Obtaining the kernel sources for an Ubuntu release using git

The source for each release is maintained in its own git repository on Launchpad.

The git repository is listed in the Vcs-Git: header in the source package and is of the following form:

For example, the standard Cosmic kernel is available at:

There is a tree for each of the currently supported releases as well as any open development and upcoming releases:

ubuntu-kernel/ubuntu/+source/linux/+git/groovy

ubuntu-kernel/ubuntu/+source/linux/+git/focal

ubuntu-kernel/ubuntu/+source/linux/+git/bionic

Replace your intended OS series in the above, and pull the source for the kernels you need.

The distro kernel is always on the master branch in these repositories. Each release also has a master-next branch containing the commits that will go onto the master branch and become the next release for that release.

A number of releases also have other source packages which represent other related but divergent kernels for other purposes. For example, there is a specialized AWS kernel available in the linux-aws source package. (Previously these sorts of things were done in Topic Branches and some older kernels and projects still use them.)

If you cannot use the git protocol (perhaps because of a firewall), you can use the slower http protocol. For example:

Obtaining a copy

To obtain a local copy you can simply git clone the repository for the release you are interested. The git command is part of the git package.

For example to obtain the Bionic tree:

This will download several hundred megabytes of data. If you plan on working on more than one kernel release you can save space and time by downloading the upstream kernel tree. Note that once these two trees are tied together you cannot remove the virgin Linus tree without damage to the Ubuntu tree:

In each case you will end up with a new directory ubuntu- containing the source and the full history which can be manipulated using the git command from within each directory.

By default you will have the latest version of the kernel tree, the master tree. You can switch to any previously released kernel version using the release tags. To obtain a full list of the tagged versions in the release as below:

To look at the Ubuntu-5.4.0-52.57 version you can simply checkout a new branch pointing to that version:

You may then manipulate the release — for example, by adding new commits.

Maintaining local changes

During development, the kernel git repository is being constantly rebased against Linus’ tree. IOW, Ubuntu specific changes are not being merged, but rather popped off, the tree updated to mainline, and then the Ubuntu specific changes reapplied; they are rebased. There are two ways to track the kernel git tree, depending on whether you have local changes or not:

No Local Changes

Preserve Local Changes

Pushing changes to the main repo

Since the main repo is not publicly writable, the primary means for sending patches to the kernel team is using git format-patch. The output from this command can then be sent to the kernel-team mailing list.

Alternatively, if you have a publicly available git repository for which changes can be pulled from, you can use git request-pull to generate an email message to send to the kernel-team mailing list.

Using Commit templates

In debian/commit-templates/ in the source tree there are several templates that should be used when committing changes that you expect to be integrated with the Ubuntu kernel repo. The commit templates contain comments for how to fill out the required information. Also note that all commits must have a Signed-off-by line (the «-s» option to git commit). A typical git commit command will look like:

Note that the -e (edit) option must follow the -F option, else git will not let you edit the commit-template before committing. The primary one you will use is the patch template. It is commented heavily, so should be self explanatory. Some templates do not require editing such as the bumpabi and updateconfigs templates. An example commit log will look like this:

The first line is critical and should summarise the change. The prefix for the line defines the type of the commit (see below). The last line should contain your sign-off for the patch and any acks it has received. The remainder of the text should concisely describe the change.

UBUNTU: SAUCE:

a kernel source modification which is specific to Ubuntu

UBUNTU: [Config]

a change to the kernel configuration

any other change to the debian packaging for the kernel

upstream kernel patches

Patch acceptance criteria

In general, Ubuntu will apply the same criteria applicable to upstream kernel. Here is a checklist of reading and tools related to posting kernel patches:

If you are creating a new file, it is helpful to run it through cleanfile and/or Lindent before creating a patch
If you have generated a patch, it helps running it through checkpatch.pl and cleanpatch if necessary
Also, using the commit template described above is a good idea for Ubuntu-specific patches

[old] Developers with access to kernel.ubuntu.com

The kernel team has a git repo located on kernel.ubuntu.com (AKA zinc.ubuntu.com) in /srv/kernel.ubuntu.com/git/ubuntu.

You can, if you want, create a clone for yourself in your directory, and just have your changes pulled when ready.

Suggested way to do this:

You can now push your changes to this tree via ssh. Note the -l -n -s options do a few special things, mainly making your repo share objects with ours (saves space).

Now you need to run git update-server-info in your tree so that it is available over http transport

For older versions of git instead of using the post-update hook use

To work on your branch, now clone to your local machine from the same origin tree (not the tree you just created on zinc — this is only for pushing to):

Suggested method for keeping this tree synced with the ubuntu tree, instead of git pull, is to do:

This will keep your changes on top of the original tree (as opposed to being merged). This is also a good idea because during development (e.g. while following the upstream git repo), we frequently rebase to linux-2.6.git upstream, so the HEAD is not always suitable for pull/merge.

Kernel/Dev/KernelGitGuide (последним исправлял пользователь daxtens 2018-12-10 05:42:17)

Источник

Linux kernel «historical» git repository with full history

I think many developers like to investigate sources with the help of git gui blame . As explained in the commit for Linux-2.6.12-rc2 (also mirrored at Github), it needs to have special historical Linux repository for this purpose.

Linux-2.6.12-rc2

Initial git repository build. I’m not bothering with the full history, even though we have it. We can create a separate “historical” git archive of that later if we want to, and in the meantime it’s about 3.2GB when imported into git — space that would just make the early git days unnecessarily complicated, when we don’t have a lot of good infrastructure for it.

I have looked at a lot of the prepared historical repositories but I didn’t find one containing changes going back to version zero, so I gave up and am asking this question here.

4 Answers 4

Here is my setup.

I have a repository with a clone of the following remotes:

And the following grafts ( info/grafts ):

With these grafts, I have an unbroken view of the kernel history since 0.01. The first graft glues together the very first release in Linus’ repository with the corresponding release of tglx/history.git . The second graft glues together tglx/history.git and davej/history.git .

There are a few older versions missing, and the older versions have release granularity instead of patch granularity, but this is the best setup I know of.

Edit: Dave Jones pointed me to http://www.archive.org/details/git-history-of-linux, which seems to be exactly what you want.

Here is a review of available 2018 options with a focus on tag availability and date correctness.

https://archive.org/download/git-history-of-linux/full-history-linux.git.tar

Developed by Dave Jones, and made available on archive.org .

• Covers early versions to 2010.
• 244,464 commits
• Just 184 tags, covering versions in 2.6. The tags that should have been created for all versions seem to be missing.
• Early commits have realistic dates, but incorrect times ( 11:00:00 199X -0600 ).
• Some dates seem to be incorrect. For example, both 2.1.110 and 2.1.111 are dated Wed May 20 11:00:00 1998 -0600 , although the latest file in the 2.1.111 snapshot is dated 1998-07-25 09:17 .
• The creation process is documented on GitHub and seems very thorough.

https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/

Created by Thomas Gleixner.

• Covers 2.4.0 to 2.6.12-rc2.
• Contains 170 tags covering 2.5.X and 2.6.X.
• 63,428 commits
• Dates are correct.
• Contains patches converted into commits.

https://github.com/mpe/linux-fullhistory

Created by Michael Ellerman, derived from work by Yoann Padioleau, based on historical trees reconstructed by Dave Jones and Thomas Gleixner, and Linus’ mainline tree.

• Covers full history
• Provides only 558 tags, mostly starting at 2.0.0.
• 790,471 commits
• Same issues with dates as in Dave Jones’s repo.
• Uses replace objects instead of grafts.

https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/

Owned by the Linux history team.

• Covers early versions to 2.6.33-rc5.
• 1710 tags, starting with 0.10, covering most early versions.
• 244,774 commits
• Most historic versions are incorrectly dated Fri Nov 23 15:09:04 2007 -0500 .

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

Modern Linux development.

• Covers 2.6.12-rc2 (2005) until today
• 569 tags
• 777,419 commits (August 2018)
• Proper commits

Источник

Linux kernel development для самых маленьких

Любой программист знает, что теоретически он может внести свой посильный вклад в развитие Linux ядра. С другой стороны, подавляющее большинство уверено, что занимаются этим исключительно небожители, а процесс контрибьюта в ядро настолько сложен и запутан, что обычному человеку разобраться в нём нет никакой возможности. А значит, и надобности.
Сегодня мы попробуем развеять эту легенду и покажем, как абсолютно любой инженер при наличии достойной идеи, воплощённой в коде, может предложить ее на рассмотрение Linux community для включения в ядро.

0. Подготовка

Как и перед любой инженерной операцией, всё начинается с подготовки своего рабочего места. И первейшее здесь действие — это завести себе аккаунт с адекватным именем. В идеальном мире это будет просто транскрипция имени и фамилии. Если за учётку вроде MamkinC0d$r или Developer31337 в других местах пальцем в вас тыкать не будут, то правила LKC (Linux kernel community) такое прямо запрещают — инкогнито контрибьютить в ядро не принято.

Далее вам понадобится место на локальной машине. Сама папка Linux со скачанными исходниками весит чуть меньше 3-х гигов. Но если ядро пробовать собирать, то вместе с модулями займёт все 30 GB.

Захотелось собрать несколько веток? Умножаем 30 на число веток.
И помним — скорость сборки прямо связана с количеством доступных ядер! Больше ядер — быстрее соберётся. Так что не стесняйтесь выделять под это самую мощную машину.

1. Mail

Самый спорный и поэтому регулярно вызывающий споры момент — это канал коммуникации с LKC. Он безальтернативно один. Почта. Причём сообщения отправляются по классике через smtp.

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

Но, как принято в уютном мирке ядра, Линус хлопнул кулаком по столу — и все пишут письма. Возможно, буквально завтра это изменится, но на момент выхода статьи это письма и только письма.

Какой email-client выбрать — есть рекомендации. Самым рекомендуемым почтовым агентом для LKC остаётся mutt. Да, тот самый текстовый почтовый клиент, от которого сводит олдскулы. Для начала mutt нужно поставить (я думаю, со своим пакетным менеджером вы и сами справитесь), а потом задать параметры в файле

Но почты недостаточно. Без Git никуда.

2. Git

Прежде чем что-то делать с исходниками ядра, нужно настроить Git. Можно конфигурировать файлы напрямую, но есть упрощающая жизнь утилита git config, через которую можно регулировать все аспекты работы Git’a.

Внутри есть три уровня настроек: общие для всех пользователей системы и для всех репозиториев (git config —system), общие для всех репозиториев конкретного пользователя (git config —global), отдельные для каждого репозитория (git config —local).

Глобальные настройки хранятся в /etc/gitconfig, настройки пользователя в

/.config/git/config, а настройки отдельных репозиториев хранятся в файле config в каталоге .git/config.

В общем случае будет достаточно законфигурировать файл для пользователя

/.gitconfig . Основная идея: при отправке коммитов должно отображаться ваше корректное имя.

Примечательно, что параметр sslVerify = true препятствует работе с Git напрямую через git://git.kernel.org и форсит доступ только через https://git.kernel.org . Так, наверное, секьюрнее, хотя какого-то смысла я в этом не вижу. Но, может, чего-то не знаю?

signOff обязателен, чтоб в коммитах была информация об авторе. По идее, надо бы, чтобы коммиты подписывались. Была тут недавно статья на эту тему.

Отправка патча выполняется командой git send-email. У git send-email есть несколько параметров с участием smtp, которые можно (и нужно) переопределить.

Полезный параметр —smtp-debug=1. Осуществляет логирование SMTP запросов и ответов, что помогает при разборе проблем с настройками почты. Например, я столкнулся с тем, что почтовый сервер, на котором есть у меня почтовый ящик, не поддерживает TLS. Возможны проблемы с аутентификацией, а сообщения об ошибке git send-email выдаёт не особо разнообразные и адекватные.

Можно задавать пароль к почте через параметр —smtp-pass=p4ssw0rd или вообще захардкорить в конфиге, но это это для тех, кому терять нечего. Но если каждый раз вводить пароль лень, то есть некий хак: если username был задан (через —smtp-user или sendmail.smtpUser), а пароль не указан, тогда пароль получается через git-credential.

Итак, окно в большой мир прорубили. Можно переходить к воплощению своей грандиозной идеи в коде.

3. Coding

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

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

Операция довольно долгая, так что смело можно идти за кофе или на обед. А если попробовать ускорить процесс, отказавшись от истории, то работать с «этим» будет невозможно.

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

Если бродить вслепую по гуглу не хочется, то вся максимально полезная информация по ядру сконцентрирована тут. Прочитать стоит действительно всё. Особенно правильно будет начать с How To о том, как правильно коммуницировать. Потому что мейнтейнеры, как правило, люди весьма занятые, и вникать в невнятно составленные письма им никакого интереса. Да и вам будет обидно, если из-за плохого описание ваше детище не примут в апстрим.

И вот свой небольшой и эффективный код вы написали, отладили, всё протестировали и готовы отправлять на рассмотрение. Но не спешите этого делать. Для начала обязательно проверьтесь на code style. В этом вам поможет ./script/checkpatch.pl . Для этого сделаем патч и отправим его на проверку.

После того, как пройдёт первое удивление и вы доустановите необходимые компоненты для python2 типа ply и git (который у меня так и не установился), наступит чудесное время исправления ошибок и ворнингов. По результатам которых вы а) поймёте, что красивый код писать вы не умеете б) потеряете всякое желание что-то куда-то отправлять. Ведь даже если отбросить все шутки, ещё можно как-то смириться с тем, что длина строк ограничена 100 символами (это начиная с версии 5.7, раньше так было вообще 80). Но вот такие места оставляют неизгладимое впечатление:

Для .h файлов строка с информацией о лицензии должна быть в ремарках / * */, а для *.c файлов должна быть в ремарках //. Такое запросто выбьет кого угодно из душевного равновесия. Вопрос: «Зачем?!» до сих пор болтается в моей голове, хотя есть вера в то, что это не просто ошибка в скриптах.

Кстати, чтобы просто проверить один файл достаточно вызвать

Можно прикрутить этот вызов к git, чтобы автоматически запускался этот скрипт при попытке что-то зачекинить.

Ещё важное замечание: clang-format добрался и до ядра Linux. Файл .clang-format расположился в корне ядра в кучке с другими конфигами. Но я не советую добавлять его в хук для git. Лучше всего корректно настроить среду разработки и запомнить code style. Лично мне не понравилось как он делает переносы длинных строк. Если вдруг строка оказалась длиннее допустимой, то скорее всего функция, в которой эта строка расположилась, является кандидатом на рефакторинг, и лучше его не откладывать. С другой стороны, если у вас много уже готового кода который нужно адаптировать для ядра — clang-format может сильно облегчить вам задачу.

4. Kernel build

Несмотря на то, что процесс описан в других статьях тут и тут, я все же повторюсь.

По шагам процесс сборки ядра довольно прост, если не вдаваться в детали. Для начала ставим необходимые пакеты (использовался Debian 10):

Это без компилятора и обычного для С/С++ разработчика набора программ.
Запускаем конфигурацию:

Тут есть интересный аспект: в качестве шаблона будет браться config ядра от вашего боевого ядра, которое, скорее всего, подготовлено дистрибьютером. Для Debian 10 сборка проходит успешно, если в конфиге потереть информацию о встраиваемых в ядро сертификатах.

Перед попыткой собрать проверьте, что нужные программы уже установлены. Список тут. Чтобы собрать само ядро:

Этого достаточно для проверки собираемости, но недостаточно для запуска ядра в системе, так как без модулей ядро на реальной системе практически беспомощно.

Если какой-то модуль не собирается, просто вырубите его в ближайшем Makefile-е (если 100% уверены, что не пытались в нём что-то улучшить). Наверняка он вам не пригодится, и тратить время на исправления смысла нет.

Теперь можно деплоить то, что получилось, на эту же систему.

Хотя, конечно, экспериментировать с ядром на той же машине, где ведётся разработка — дело рискованное.

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

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

Update: Как верно заметил gavk, ядро давно уже умеет собирать пакеты, причём как для deb, так и для rpm.
Команда

выводит весь ассортимент. Так что команда

должна собрать пакет с ядром.

5. Patches

Вот теперь мы действительно подготовили код для отправки. Лучше всего, чтобы это был единственный коммит. Так проще делать ревью и так быстрее вам ответят. Всё проверив, наконец-то делаем коммит.

Ещё можно комментарии к коммиту дополнить в человеческом текстовом редакторе.

И теперь его можно оформить в виде того самого письма. Правила хорошего тона, или best practice, если угодно — это 75 символов на строку.

В результате получите два файла. В первом 000-cover-letter.patch нужно указать заголовок письма «Subject» и основное описание патча. В описании патча пишем, для чего он создавался, кому он сделает жизнь на нашей планете лучше и каким образом. Только не словоблудим про космические корабли в Большом театре, а пишем лаконично и по делу. И не в коем случае не пишите корпоративную лабуду а-ля «Без этого патча мой бизнес встанет, меня уволят, а дети мои умрут от голода». Нет, строго по существу: «Увидел вот такую проблему вот тут, починить решил вот таким образом, исходники патча прилагаю». Всё, вы восхитительны! А если не превысили 75 символов на строку, то восхитительны в квадрате.

А ещё один волшебный скриптик ./scripts/getmaintainers.pl

позволит узнать, кому письмо отправлять.

И вот он, момент отправления письма, ради которого всё и затевалось:

Дальше остаётся только сидеть и ждать ответного письма, где вам скорее всего скажут, что всё здорово, но надо ещё сделать вот это и поправить вот здесь. Возможно, придётся доказывать, что ваш функционал действительно новый и не создаёт дублирования. Хотя могут и сразу всё принять, сказав большое спасибо (шутка :-).

После того, как ваш патч был принят, крайне желательно удалить свою ветку.

6. Debuging

И чуть-чуть про отладку. Бонус «на сладкое» для начинающих разработчиков ядра, так сказать.

Как правило, при ошибке вы получаете лог с calltrace-ом. Там указываются имена функций и смещения. Примерно вот так:

Так вот, чтобы понять, в каком месте функции произошла ошибка, достаточно запустить дебагер с подгруженным в него модулем:

Важно, чтобы в модуле сохранились символы (stripped модуль вам тут не поможет).

Выполнив команду list

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

И на этом позвольте откланяться.

Буду рад вопросам и замечаниям в комментариях.

Источник