Git linux kernel source

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)

Источник

Git linux kernel source

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

Источник