SLFO-pool/kernel-source-rt
SHA256
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sync from SUSE:SLFO:Main kernel-source-rt revision 2df16d0184121ab07081e9ca44e4b094

Browse Source
This commit is contained in:
Adrian Schröter 2024-05-03 14:13:34 +02:00
commit 865fc6e9f8
81 changed files with 371240 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
.gitattributes vendored Normal file
View File

@ -0,0 +1,23 @@
## Default LFS
*.7z filter=lfs diff=lfs merge=lfs -text
*.bsp filter=lfs diff=lfs merge=lfs -text
*.bz2 filter=lfs diff=lfs merge=lfs -text
*.gem filter=lfs diff=lfs merge=lfs -text
*.gz filter=lfs diff=lfs merge=lfs -text
*.jar filter=lfs diff=lfs merge=lfs -text
*.lz filter=lfs diff=lfs merge=lfs -text
*.lzma filter=lfs diff=lfs merge=lfs -text
*.obscpio filter=lfs diff=lfs merge=lfs -text
*.oxt filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.rpm filter=lfs diff=lfs merge=lfs -text
*.tbz filter=lfs diff=lfs merge=lfs -text
*.tbz2 filter=lfs diff=lfs merge=lfs -text
*.tgz filter=lfs diff=lfs merge=lfs -text
*.ttf filter=lfs diff=lfs merge=lfs -text
*.txz filter=lfs diff=lfs merge=lfs -text
*.whl filter=lfs diff=lfs merge=lfs -text
*.xz filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text
*.zst filter=lfs diff=lfs merge=lfs -text

6
README.KSYMS Normal file
View File

@ -0,0 +1,6 @@
This file is a place holder for the kernel-syms{,-rt} package. It is used
to group build dependencies for all kernel flavors.
The KMP build process will build KMPs against all installed kernel flavors
automatically. If you don't need to build against other flavors than the
ones you've already installed - it is safe to uninstall this package.

316
README.PATCH-POLICY.SUSE Normal file
View File

@ -0,0 +1,316 @@
SUSE Linux Enterprise Patch Policy
==================================
Summary
-------
The SUSE Linux Enterprise (SLE) patch policy mirrors the mainline Linux
community's policy for accepting changes. Each commit must contain a small and
"obvious" change that can be reviewed individually and, once applied, be able to
be used as a bisection point. The kernel should be able to build and boot
between each applied patch. Since the SLE kernel is based on an official
upstream kernel release and is followed by a hardening process, we expect that
nearly all of the patches applied to the base release will be from subsequent
official upstream releases intended to address specific issues or to allow for
hardware/feature enablement.
Background
----------
Before covering the policy itself, we'll discuss a bit of background on how the
source code tree is organized. If you've used the SLE kernel source tree
at <https://github.com/SUSE/kernel-source> before, you've probably noticed that,
unlike the mainline Linux kernel, we don't use a source-level Git repository as
our "base". Instead, we use an official kernel.org Linux tar archive as the base
and add a series of patches on top of it. This carries with it several benefits.
The biggest is that we add metadata "tags" to our patches that allow us to
easily associate patches with particular feature requests, bug reports, and/or
the pedigree of the patch. Due to the nature of some of our feature requests, we
must also occasionally carry patches that, for one reason or another, haven't
been accepted into the mainline kernel repository yet. With a full Git
repository, it would be difficult to associate the initial commit for a
particular feature with any subsequent changes to it. Another benefit is more
superficial: with the use of separate patches, we and our users are able to
tell, at a glance, which patches are in any given kernel release simply by
looking at the source package.
This approach works well but has limited options for typical debugging
techniques such as bisection. The application of the patch series results in our
fully operational SLE kernel but stopping the patch series midway can result in
an unbuildable source tree. To help this and similar scenarios, we publish also
a fully expanded Git repository at <https://github.com/SUSE/kernel> which
exactly represents the code as if it were originally used as a standard source
code tree repository. This allows us to work with the individual patches *and*
have the ability to bisect the tree as the changes are applied. It also makes it
easier for partners unfamiliar with how our source tree works to make the
transition.
Format
------
The SLE patch format follows very closely what you would see on any mailing list
associated with Linux kernel development. A SLE patch is formatted like an
RFC822 mbox-style mail message, with a few extensions. If the patch is coming
from the mainline Linux repository or a subsystem maintainer repository, SUSE
has tools that can make adding these tags nearly painless.
Each patch should contain the "From" and "Subject" headers found in any email
message. The From should contain the name and email address of the patch author.
The Subject should contain a short description of the patch, prefixed with the
subsystem affected.
For instance:
From: Jeff Mahoney <jeffm@suse.com>
Subject: init: print hello world at boot time
Beyond that, we require several more headers, the full description of the patch,
the certification tags used in the mainline kernel, and the patch contents.
The required headers are as follows:
* Git-commit: [a-f0-9]{40}
Contains the SHA-1 Git commit ID of the patch in either the mainline kernel
repository or an official maintainer repository.
* Git-repo: URL-to-git-repo (starting with `git://`)
The URL to the Git repository containing the commit. This tag can be omitted
if the commit is from the mainline kernel repository.
* Patch-mainline: vMajor.Minor.Patch{-optional-rc}
The official kernel release that contains this patch. In the case of a patch
accepted into a maintainer branch, "Queued in subsystem maintainer repo" can
be used. If the patch has been submitted to a subsystem mailing list for
review and is nearly certain to be accepted,
"Submitted <date> <list@site.org>" can be used. Otherwise, if the patch will
never be in the upstream kernel, e.g. in the case of vendor-specific version
numbers, etc., then "No" followed by the reason why it will not be accepted
(or submitted). Please note that the reason must be compelling for it to be
allowed into our kernel repository.
* References: list of references
A specific reason must exist for each patch to be included into the kernel
repository. It can be a fix in response to a bug report or a patch submitted
as part of the feature development cycle for a release. We use a shorthand to
indicate why a particular patch will be included and it's possible to use more
than one.
For feature requests, the feature will have to have gone through our feature
tracking tool, a Jira instance at <https://jira.suse.com/>. Each feature
request will have an ID associated with it and it can be added to the
References tag using jsc#id, e.g. jsc#PED-12345.
For fixes to bug reports or patches for feature requests submitted via
Bugzilla at <https://bugzilla.suse.com/>, the shorthand is bsc#number. Other
shorthands referring to different Bugzilla instances are possible too, such as
bko, for <https://bugzilla.kernel.org/>.
Next is the full description of the patch, which should explain why the patch is
needed and an overview of what it does.
The last "header" portion of the patch contains the certification tags, which
consist of "Signed-off-by" and "Acked-by". We and the upstream Linux community
depend on patch submitters to "own" their submission and certify they have the
right to submit code to the kernel repository. For patches coming from the
mainline Linux kernel repository, the certification tags are already in place
and only the submitter's tag needs to be added, unless one is also already part
of the original patch. Likewise, the SUSE engineer who includes the submission
in our kernel tree will add their own "Acked-by" tag.
The remaining part of the patch is the actual diff with changes. The patch
content should be in the "-ab" format where the patch header itself only
contains the filename without any timestamps. An optional `diffstat -p1` output
may also be included.
Here's an example of a complete patch:
```
From: Upstream Committer <coder@somesite.com>
Subject: init: print hello world on boot
Patch-mainline: v3.8-rc1
Git-commit: deadbeefc0ffeeb1a4b1a4b1a4b1a4b1a4b1a4b1a4
References: jsc#PED-12134 bsc#23123
The kernel started off like every other project. Let's add the hello
world message in honor of its roots.
Signed-off-by: Upstream Committer <coder@somesite.com>
Tested-by: Bill User <bill.user@example.com>
Acked-by: Jeff Mahoney <jeffm@suse.com>
---
init/main.c | 1 +
1 file changed, 1 insertion(+)
--- a/init/main.c
+++ b/init/main.c
@@ -807,6 +807,7 @@ static noinline int init_post(void)
system_state = SYSTEM_RUNNING;
numa_default_policy();
+ printk("Hello world!\n");
current->signal->flags |= SIGNAL_UNKILLABLE;
```
Patch inclusion rules
---------------------
As mentioned in the summary, we expect that most patches to the SLE kernel will
come from subsequent official upstream kernel releases, or from subsystem
maintainer repositories where the patch is on its way to become a part of an
official upstream Linux release. The SLE kernel contains hardware enablement
driver enhancement/backports for a wide range of devices offered by many
vendors. In many cases, the drivers are self-contained but many others have
shared dependencies on common infrastructure.
The shared dependencies on common infrastructure combined with the need to be
able to bisect the resulting kernel means that we must require all partners to
submit patch series consisting of individual patches that match upstream
commits. In the case where a commit affects multiple drivers, it is acceptable
to only include the portions that affect a particular driver as long as it is
annotated by appending "(partial)" to the Git-commit line and documenting what
is included or dropped. An example using the patch tools is included below.
Tools
-----
We understand that there are a bunch of rules to follow and that implementing
them all can be tedious. SUSE has a set of tools to make working with the
patches a lot easier. They are called patchtools and published at
<https://download.opensuse.org/repositories/Kernel:/tools/>.
Two important tools are included: fixpatch and exportpatch. Fixpatch adds
missing headers and formatting to existing patches, assuming there's at least a
Git-commit tag present. Exportpatch, given a list of commit IDs on the command
line, searches for each commit in the configured repositories and exports the
patches.
Exportpatch has a number of options, the following list shows the most useful
ones:
* `-w` | `--write`
Write out each commit into a separate file. The filenames are based on the
subject of the header and they get output on stdout for use directly in a
series file.
* `-d DIR` | `--dir=DIR`
Write out each commit into a designated directory. The default is to write
into the current directory.
* `-F REF` | `--reference=REFERENCE`
Add a References tag to the patch output using the specified reference, can be
repeated multiple times.
* `-x EXTRACT` | `--extract=EXTRACT`
It it sometimes desirable to split out chunks of patches that affect only a
particular section of the code. This option accepts pathnames to extract.
Anything not specified will be skipped. Paths ending with `/` designate
everything under that hierarchy. This also adds the "(partial)" notation to
the Git-commit tag and adds a Patch-filtered tag indicating which paths were
used to extract.
Refer to the exportpatch(1) manual page for more details and a complete list of
all options.
One useful feature of exportpatch is that 3-way merge diffs are handled
automatically such that a new, exact 2-way diff is generated. Note that both the
`-x` option and the automatic handling of merge commits can generate empty
patches. Such patches are skipped entirely and no files are generated.
As a quick example, the following invocation would generate patches necessary
for a backport of the ixgbe driver from v3.2 against the v3.0 kernel:
$ exportpatch -w -d ixgbe \
-x drivers/net/ixgbe/ -x drivers/net/ethernet/intel/ixgbe/ \
-F "jsc#PED-12345" -F "bsc#12354" \
$(git log v3.0..v3.2 --pretty=oneline -- \
drivers/net/ixgbe drivers/net/ethernet/intel/ixgbe | \
cut -b 1-40) \
> ixgbe/series
The tool automatically adds an Acked-by tag to the created patches unless you
were involved in the original upstream commit process. Be aware that the
produced result (obviously) doesn't include any infrastructure changes that
might be needed for the patches to build.
The first patch in the series looks like this:
```
From 6403eab143205a45a5493166ff8bf7e3646f4a77 Mon Sep 17 00:00:00 2001
From: Joe Perches <joe@perches.com>
Date: Fri, 3 Jun 2011 11:51:20 +0000
Subject: drivers/net: Remove unnecessary semicolons
Git-commit: 6403eab143205a45a5493166ff8bf7e3646f4a77 (partial)
Patch-mainline: v3.1-rc1
References: jsc#PED-12345 bsc#12354
Patch-filtered: drivers/net/ixgbe/ drivers/net/ethernet/intel/ixgbe/
Semicolons are not necessary after switch/while/for/if braces
so remove them.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jeff Mahoney <jeffm@suse.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 4 ++--
drivers/net/ixgbe/ixgbe_common.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -1157,7 +1157,7 @@ s32 ixgbe_init_fdir_signature_82599(struct ixgbe_hw *hw, u32 pballoc)
default:
/* bad value */
return IXGBE_ERR_CONFIG;
- };
+ }
/* Move the flexible bytes to use the ethertype - shift 6 words */
fdirctrl |= (0x6 << IXGBE_FDIRCTRL_FLEX_SHIFT);
@@ -1245,7 +1245,7 @@ s32 ixgbe_init_fdir_perfect_82599(struct ixgbe_hw *hw, u32 pballoc)
default:
/* bad value */
return IXGBE_ERR_CONFIG;
- };
+ }
/* Turn perfect match filtering on */
fdirctrl |= IXGBE_FDIRCTRL_PERFECT_MATCH;
--- a/drivers/net/ixgbe/ixgbe_common.c
+++ b/drivers/net/ixgbe/ixgbe_common.c
@@ -1292,7 +1292,7 @@ static s32 ixgbe_ready_eeprom(struct ixgbe_hw *hw)
udelay(5);
ixgbe_standby_eeprom(hw);
- };
+ }
/*
* On some parts, SPI write time could vary from 0-20mSec on 3.3V
@@ -1374,7 +1374,7 @@ static void ixgbe_shift_out_eeprom_bits(struct ixgbe_hw *hw, u16 data,
* EEPROM
*/
mask = mask >> 1;
- };
+ }
/* We leave the "DI" bit set to "0" when we leave this routine. */
eec &= ~IXGBE_EEC_DI;
```

434
README.SUSE Normal file
View File

@ -0,0 +1,434 @@
Working with the SUSE Kernel Sources
====================================
This document gives an overview of how SUSE Linux kernels are created, and
describes tasks like building individual kernels and creating external kernel
modules.
Overview
--------
The SUSE kernels are generated from the upstream Linux kernel sources found at
<https://kernel.org/>, on top of which a number of patches are applied. The
expanded kernel source tree is configured and built, resulting in a binary
kernel.
The add-on patches and configuration files are maintained in a Git repository at
<https://github.com/SUSE/kernel-source>, with an alternative mirror at
<https://github.com/openSUSE/kernel-source>.
A script named `scripts/tar-up.sh` packs up the files in the repository in a
form suitable for rpmbuild. When building the RPM packages, the following
binary packages get created:
* kernel-source
The kernel source tree, generated by unpacking the vanilla kernel sources and
applying the patches. The kernel sources are used by a number of other
packages. They can also be used for compiling additional kernel modules.
* kernel-devel
A complement of the kernel-source package that is needed to build external
modules.
* kernel-`$FLAVOR`
A number of binary kernels, for example, kernel-default for standard use,
kernel-debug with extra debugging features, etc. These packages are all
generated from the same kernel sources, and differ in the kernel
configurations used.
* kernel-`$FLAVOR`-base
A subset of kernel-`$FLAVOR`, for use in virtualized guests that only require
a few device and filesystem drivers.
* kernel-`$FLAVOR`-devel
The files used for generating kernel module packages for use with
kernel-`$FLAVOR`.
* kernel-syms
A meta package that pulls in the relevant kernel-`$FLAVOR`-devel packages for
a given architecture.
The repository contains configuration files (`.config`) for all SUSE kernel
flavors. All configuration files are included in the dependencies of the
kernel-syms package, see [Where to find configuration
files](#where-to-find-configuration-files) below.
In the installed system, the kernel-source package installs files in the
following directories:
* `/usr/src/linux-$VERSION-$RELEASE/`
The kernel sources.
* `/usr/src/linux`
A symbolic link to `/usr/src/linux-$VERSION-$RELEASE/`.
* `/usr/share/doc/packages/kernel-source-$VERSION-$RELEASE/`
This document.
The kernel-`$FLAVOR`-devel packages install the following files:
* `/usr/src/linux-$VERSION-$RELEASE-obj/$ARCH/$FLAVOR/`
Kernel build object files for one kernel flavor. These files are used for
compiling additional kernel modules.
* `/usr/src/linux-obj/$ARCH/$FLAVOR`
A symbolic link to `/usr/src/linux-$VERSION-$RELEASE-obj/$ARCH/$FLAVOR/`.
Compiling your own kernel
-------------------------
The kernel sources are found in the kernel-source package. A binary kernel can
be built from these sources as follows:
1. Install the kernel-source package.
2. Create a build directory for use in configuring and building the kernel.
Using `/usr/src/linux/` directly requires root privileges and will cause
problems if you need to build kernel modules for other installed kernels.
3. Configure the kernel, see [How to configure the kernel
sources](#how-to-configure-the-kernel-sources). For example,
`make -C /usr/src/linux O=$PWD oldconfig`.
4. Build the kernel and all its modules by invoking `make`.
5. Make sure that `/etc/modprobe.d/10-unsupported-modules.conf` contains
allow_unsupported_modules 1
otherwise modprobe will refuse to load any modules.
6. Install the modules and kernel: `make modules_install`, followed by
`make install`. This automatically creates an initrd for the new kernel and
adds an entry to the GRUB boot menu.
Instead of building binary kernels by hand, you can also build one of the
kernel-`$FLAVOR` packages using RPM.
Building additional (external) modules
--------------------------------------
A single binary kernel module generally only works for a specific version of the
kernel source tree, for a specific architecture and configuration. This means
that for each binary kernel that SUSE ships, a custom module must be built. This
requirement is to some extent relaxed by the modversion mechanism: modversions
attach a checksum to each symbol (function or variable) exported to modules by
the kernel. This allows to use kernel modules that have been built for a kernel
with a different version or release number in many cases, as long as none of the
symbols the module uses have changed between the two kernel versions.
When releasing maintenance or security update kernels for a specific product, we
carefully try to keep the kernel ABI stable. Despite this, we sometimes have no
choice but to break binary compatibility. In this case, those kernel modules
must be rebuilt.
Additional kernel modules for one of the SUSE kernel flavors can be built in the
following ways:
1. by doing an ad-hoc module build, using one of the standard configurations in
`/usr/src/linux-obj/$ARCH/$FLAVOR`, or
2. by creating a Kernel Module Package (KMP) as described in the Kernel Module
Packages Manual,
<https://documentation.suse.com/sbp/all/html/SBP-KMP-Manual-SLE12SP2/index.html>.
The first method involves the following steps:
1. Install the kernel-devel package.
2. Install the kernel-`$FLAVOR`-devel package. This is necessary for symbol
version information (`CONFIG_MODVERSIONS`).
3. Compile the module(s) by changing into the module source directory and typing
`make -C /usr/src/linux-obj/$ARCH/$FLAVOR M=$PWD`. Substitute `$ARCH` and
`$FLAVOR` with the architecture and flavor for which to build the module(s).
If the installed kernel sources match the running kernel, you can build
modules for the running kernel by using the path
`/lib/modules/$(uname -r)/build` as the `-C` option in the above command.
(`build` is a symlink to `/usr/src/linux-obj/$ARCH/$FLAVOR`.)
4. Install the module(s) with
`make -C /usr/src/linux-obj/$ARCH/$FLAVOR M=$PWD modules_install`.
Whenever building modules, please use the kernel build infrastructure as much as
possible, and do not try to circumvent it. The `Documentation/kbuild` directory
in the kernel sources documents kbuild makefiles.
Supported vs. unsupported modules
---------------------------------
As an extension to the mainline kernel, modules can be tagged as supported
(directly by SUSE, or indirectly by a third party) or unsupported. Modules which
are known to be flakey or for which SUSE does not have the necessary expertise
are marked as unsupported. Modules for which SUSE has third-party support
agreements are marked as externally supported. Modules for which SUSE provides
direct support are marked as supported.
The support status of a module can be queried with the modinfo tool. Modinfo
will report one of the following:
* direct support by SUSE: "supported: yes",
* third-party support: "supported: external",
* unsupported modules: no supported tag.
At runtime, the support status of a module can be obtained by reading
`/sys/module/$MODULE/supported`.
Note that this information is available only if the module was not built
directly into the kernel. Builtin modules are implicitly supported.
The aggregated support status for the entire kernel can be inspected by reading
`/sys/kernel/supported`. The value is also included in Oopses.
The setting of the "unsupported" kernel command line parameter and
`/proc/sys/kernel/unsupported` controls whether unsupported modules can be
loaded or not, and whether or not loading an unsupported module causes a warning
in the system log:
* 0 = only allow supported modules,
* 1 = warn when loading unsupported modules,
* 2 = don't warn.
Irrespective of this setting, loading an unsupported module sets a kernel taint
flag. The taint status of the kernel can be inspected in
`/proc/sys/kernel/tainted`. The taint flags are also included in Oopses.
Relevant bits have the following meaning:
| Bit | Log | Number | Reason that got the kernel tainted |
|----:|----:|-----------:|----------------------------------------------------|
| 0 | G/P | 1 | proprietary module was loaded |
| 12 | ␣/O | 4096 | externally-built ("out-of-tree") module was loaded |
| 13 | ␣/E | 8192 | unsigned module was loaded |
| 16 | ␣/X | 65536 | module with third-party support was loaded |
| 31 | ␣/N | 2147483648 | unsupported module was loaded |
Bits 16 and 31 are specific to the SUSE kernels. Since SLE15-SP6, loading an
externally supported module does not taint the kernel, but bit 16 (X) is still
tracked per module and can be read in `/sys/module/$MODULE/taint`.
Out-of-tree modules do not have the supported flag set by default; that
is, they are marked as unsupported. For building externally supported
modules, please get in touch with the Solid Driver Program team, led by
Scott Bahling, at <mailto:soliddriver@suse.com>.
Patch selection mechanism
-------------------------
The SUSE kernels consist of the upstream kernel sources on top of which a number
of patches is applied. The file `series.conf` determines which patches are
applied and which are excluded. A script named `guards` converts `series.conf`
into a plain list of patch files to be applied. Guards decides which patches to
include and exclude based on a list of symbols. From the kernel-source.src.rpm
package, a fully patched kernel source tree can be generated from vanilla
sources + patches like this:
1. Install the package:
# rpm -i kernel-source-$RPMVERSION-$RPMRELEASE.src.rpm
2. Unpack the patches and the kernel sources:
# cd /usr/src/packages/SOURCES/
# for f in patches.*.tar.bz2; do \
tar -xjf "$f" || break; \
done
# tar -xJf linux-$SRCVERSION.tar.xz
3. Apply the patches
# for p in $(./guards < series.conf); do \
patch -d linux-$SRCVERSION -p1 < $p || break; \
done
The configuration script `config.conf` which is similar to `series.conf` is
used for configuration file selection, see the section [Where to find
configuration files](#where-to-find-configuration-files).
The file format of `series.conf` and `config.conf` should be apparent from the
comments in `series.conf` and from the guards(1) manual page. You can generate
this page by running `pod2man` on the `guards` script.
Where to find configuration files
---------------------------------
Kernel configuration files are stored in the kernel Git repository. When packing
up the repository, they end up in `config.tar.bz2`.
The kernel-`$FLAVOR` packages are based on `config/$ARCH/$FLAVOR`, for instance,
kernel-default is based on `config/$ARCH/default`. The kernel-`$FLAVOR` packages
install their configuration files as `/boot/config-$VERSION-$RELEASE-$FLAVOR`.
The config is also packaged in the kernel-`$FLAVOR`-devel package as
`/usr/src/linux-obj/$ARCH/$FLAVOR/.config`.
In addition, the running kernel exposes a gzip compressed version of its
configuration file as `/proc/config.gz`.
How to configure the kernel sources
-----------------------------------
Before a binary kernel is built or an additional loadable module for an existing
kernel is created, the kernel must be configured.
In order for a loadable module to work with an existing kernel, it must be
created with a configuration that is identical to the kernel's configuration, or
at least very close to that. Each configuration is contained in a single file.
The kernel-syms package installs configurations for all standard SUSE kernel
variants, so for building only external kernel modules it is not necessary to
configure the kernel sources.
Configuring the kernel sources for a specific configuration is straightforward:
* Locate the configuration file you want to use, see [Where to find
configuration files](#where-to-find-configuration-files) above.
* Copy the configuration to the file `.config` in your build directory.
* Run the following commands in sequence to apply the configuration, generate
version information files, etc.:
$ make -C /usr/src/linux O=$PWD clean
$ make -C /usr/src/linux O=$PWD oldconfig
If the kernel sources do not match the configuration file exactly,
`make oldconfig` will prompt for settings that are undefined. When no
`.config` file is initially copied to the target build directory, the command
automatically uses `/boot/config-$(uname -r)` as the starting configuration.
Alternatively to `make oldconfig`, you can also use `make menuconfig` for
a text menu oriented user interface.
Once this step is completed, a `Makefile` will have been created that
eliminates the need to specify the locations of the kernel source and the
build directory.
* Update the configuration appropriately for the target use.
Configuration files for SUSE kernels include settings to integrate with
signing support provided by the Open Build Service. When using such a
configuration file directly, the build might fail due to missing files needed
for signing kernel modules.
The minimal steps to enable module signing and have the kernel build
automatically generate a new key pair are as follows:
$ ./source/scripts/config --enable CONFIG_MODULE_SIG \
--enable CONFIG_MODULE_SIG_ALL --undefine CONFIG_MODULE_SIG_KEY
$ make olddefconfig
Please refer to the upstream documentation located at
`/usr/src/linux/Documentation/admin-guide/module-signing.rst` for complete
information on how to configure module signing.
How to add custom patches
-------------------------
Patches are typically added to the `patches.suse/` directory and an appropriate
place in `series.conf`. When the kernel-source package is exported from the Git
repository, the patch will be automatically added to the matching patch tarball.
If your goal is to create a kernel with only a few additional patches and you
don't want to be bothered with using the Git repository, there is an easier way.
The kernel-source SRPM ships with two empty archives that can be filled and
automatically expanded when building the kernel. You can use these to add your
own patches and config options without disturbing the rest of the kernel
package. This is useful if you are using the openSUSE Build Service and link to
the main kernel-source project instead of creating your own branch. The
advantage to this is that your project will automatically receive all the
changes that go into the main project without any further effort.
To add a patch using this mechanism, just add it to the `patches.addon.tar.bz2`
archive and add an entry to a `series` file inside the archive. The archive will
be expanded automatically after the other kernel patches when the source tree is
constructed.
Some patches may add new Kconfig options. The `config.addon.tar.bz2` archive
contains the same hierarchy as `config.tar.bz2`, but is under `config.addon/`.
You can add your new config options to files named after their `config/`
counterparts.
For example, the file used to configure the x86_64 default kernel is named
`config/x86_64/default`. To add config options to that kernel, you would create
a new file called `config.addon/x86_64/default` with the options as formatted in
a normal Linux kernel `.config` file. This is important because the kernel build
is non-interactive and will fail if it encounters new config options without
entries in the config file.
Module load paths
-----------------
Modules that belong to a specific kernel release are installed in
`/lib/modules/$VERSION-$RELEASE-$FLAVOR/`. Modules from KMPs must be installed
below `/lib/modules/$VERSION-$RELEASE-$FLAVOR/updates/` and similar: modules
below `updates/` have priority over other modules.
When KMPs contain modules that are compatible between multiple installed
kernels, symlinks are used to make those modules available to those compatible
kernels like this:
`/lib/modules/$VERSION-$OTHER_RELEASE-$FLAVOR/weak-updates/foo.ko` →
`/lib/modules/$VERSION-$RELEASE-$FLAVOR/updates/foo.ko`
Modules in the `weak-updates/` directory have lower priority than modules in
`/lib/modules/$VERSION-$OTHER_RELEASE-$FLAVOR/updates/`, and higher priority
than other modules in `/lib/modules/$VERSION-$OTHER_RELEASE-$FLAVOR/`.
Driver update disks
-------------------
A Driver Update Disk (DUD) is an update archive which makes it possible to use
new device drivers to run installation of an (open)SUSE distribution. It allows
to install the distribution on devices that were not supported at the time the
distribution was created and be able to boot the installed system afterwards
without having to manually install the new device drivers after the
installation.
For information how to create such an update, refer to the mkdud and mksusecd
tools, and their documentation:
* <https://github.com/openSUSE/mkdud>,
* <https://github.com/openSUSE/mksusecd>.
References
----------
General:
* Documentation in the kernel source tree,
* LWN.net (Linux Weekly News), <https://lwn.net/>,
* Kernel newbies, <https://kernelnewbies.org/>.
Loadable kernel modules:
* Peter Jay Salzman, Michael Burian, Ori Pomerantz: The Linux Kernel Module
Programming Guide, Version 2.6,
<https://tldp.org/LDP/lkmpg/2.6/html/index.html>.
Kernel module packages:
* Kernel Module Packages Manual, SUSE Linux Enterprise 12 SP2 or later and SUSE
Linux Enterprise 15,
<https://documentation.suse.com/sbp/all/html/SBP-KMP-Manual-SLE12SP2/index.html>,
* SUSE SolidDriver Program, <https://drivers.suse.com/doc/SolidDriver/>.

220
_constraints Normal file
View File

@ -0,0 +1,220 @@
<constraints>
<!-- Default 35GB for binary packages -->
<overwrite>
<conditions>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<disk>
<size unit="G">35</size>
</disk>
<memory>
<size unit="G">4</size>
</memory>
</hardware>
</overwrite>
<!-- 8GB RAM for kernel-syzkaller -->
<overwrite>
<conditions>
<package>kernel-syzkaller</package>
<package>kernel-source-rt:kernel-syzkaller</package>
</conditions>
<hardware>
<physicalmemory>
<size unit="G">8</size>
</physicalmemory>
</hardware>
</overwrite>
<!-- 8GB for kernel-source-rt -->
<overwrite>
<conditions>
<package>kernel-source-rt</package>
</conditions>
<hardware>
<disk>
<size unit="G">8</size>
</disk>
</hardware>
<hostlabel exclude="true">SLOW_DISK</hostlabel>
</overwrite>
<!-- 4GB for kernel-docs-rt -->
<overwrite>
<conditions>
<package>kernel-docs-rt</package>
<package>kernel-source-rt:kernel-docs-rt</package>
</conditions>
<hardware>
<physicalmemory>
<size unit="G">4</size>
</physicalmemory>
</hardware>
</overwrite>
<!-- 24GB for binary packages on armv6/7 -->
<overwrite>
<conditions>
<arch>armv7l</arch>
<arch>armv6l</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<disk>
<size unit="G">24</size>
</disk>
</hardware>
</overwrite>
<!-- 16GB of disk and 2GB of memory for binary package on s390x -->
<overwrite>
<conditions>
<arch>s390x</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<disk>
<size unit="G">16</size>
</disk>
<memory>
<size unit="G">2</size>
</memory>
</hardware>
</overwrite>
<!-- 8 CPUs for binary packages on x86 -->
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<arch>riscv64</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<jobs>8</jobs>
</hardware>
</overwrite>
<!-- 4 CPUs for binary packages on POWER -->
<overwrite>
<conditions>
<arch>ppc</arch>
<arch>ppc64</arch>
<arch>ppc64le</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<jobs>4</jobs>
</hardware>
</overwrite>
<!-- 2 CPUs for binary packages on ARM -->
<overwrite>
<conditions>
<arch>aarch64</arch>
<arch>armv6l</arch>
<arch>armv7l</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<jobs>2</jobs>
</hardware>
</overwrite>
<!-- POWER9 now required on ppc64le -->
<overwrite>
<conditions>
<arch>ppc64le</arch>
</conditions>
<hardware>
<cpu>
<flag>power9</flag>
</cpu>
</hardware>
</overwrite>
<!-- Build on recent ARMv8.1 to avoid slow builders -->
<overwrite>
<conditions>
<arch>aarch64</arch>
</conditions>
<hardware>
<cpu>
<flag>asimdrdm</flag>
</cpu>
</hardware>
</overwrite>
<!-- 45GB for binary packages on aarch64 and x86-->
<overwrite>
<conditions>
<arch>aarch64</arch>
<arch>x86_64</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<disk>
<size unit="G">45</size>
</disk>
</hardware>
</overwrite>
<!-- 52GB for binary packages on riscv64-->
<overwrite>
<conditions>
<arch>riscv64</arch>
<package>kernel-rt</package>
<package>kernel-source-rt:kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-source-rt:kernel-rt_debug</package>
</conditions>
<hardware>
<disk>
<size unit="G">52</size>
</disk>
</hardware>
</overwrite>
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<package>kernel-obs-qa</package>
<package>kernel-source-rt:kernel-obs-qa</package>
</conditions>
<sandbox>kvm</sandbox>
</overwrite>
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<package>kernel-obs-qa-xen</package>
<package>kernel-source-rt:kernel-obs-qa-xen</package>
</conditions>
<sandbox>xen</sandbox>
</overwrite>
</constraints>

5
_multibuild Normal file
View File

@ -0,0 +1,5 @@
<multibuild>
<package>kernel-rt</package>
<package>kernel-rt_debug</package>
<package>kernel-syms-rt</package>
</multibuild>

47
apply-patches Normal file
View File

@ -0,0 +1,47 @@
#!/bin/sh
#
# Given a series.conf file and a directory with patches, applies them to the
# current directory.
# Used by kernel-source.spec.in and kernel-binary.spec.in
USAGE="$0 [--vanilla] <series.conf> <patchdir> [symbol ...]"
set -e
set -o pipefail
vanilla=false
if test "$1" == "--vanilla"; then
vanilla=true
shift
fi
if test $# -lt 2; then
echo "$USAGE" >&2
exit 1
fi
DIR="${0%/*}"
SERIES_CONF=$1
PATCH_DIR=$2
shift 2
trap 'rm -f "$series"' EXIT
series=$(mktemp)
# support for patches in patches.addon/series
cp "$SERIES_CONF" "$series"
if ! $vanilla && test -e "$PATCH_DIR/patches.addon/series"; then
# make it user-friendly and automatically prepend "patches.addon/"
# if there is no "/"
sed -r 's|^([[:space:]]*)([^#[:space:]][^/]*)$|\1patches.addon/\2|' \
"$PATCH_DIR/patches.addon/series" >>"$series"
fi
(
echo "trap 'echo \"*** patch \$_ failed ***\"' ERR"
echo "set -ex"
"$DIR"/guards "$@" <"$series" | \
if $vanilla; then
sed -rn '/^patches\.(kernel\.org|rpmify)\//p'
else
cat
fi |\
sed "s|^|patch -s -F0 -E -p1 --no-backup-if-mismatch -i $PATCH_DIR/|"
) | sh

47
arch-symbols Normal file
View File

@ -0,0 +1,47 @@
#!/bin/bash
#############################################################################
# Copyright (c) 2003-2005,2009 Novell, Inc.
# Copyright (c) 2010-2022 SUSE LLC
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public License as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, contact https://www.suse.com/source-code/
#
#############################################################################
# With --list, list all known architectures, otherwise print the generic
# name for this architecture (or the one specified on command line).
if [ "$1" = "--list" ]; then
# List all known architectures
echo i386 mips{,64} sparc{,64} ppc{,64,64le} s390{,x} ia64 x86_64 alpha parisc armv6hl armv7hl arm64 riscv64
exit 0
fi
if [ -n "$1" ]; then
ARCH="$1"
else
ARCH="$(arch)"
fi
case "$ARCH" in
# from rpm --eval '%ix86'
i?86 | pentium3 | pentium4 | athlon | geode)
echo i386
;;
aarch64)
echo arm64
;;
*)
echo "$ARCH"
;;
esac

57
check-for-config-changes Normal file
View File

@ -0,0 +1,57 @@
#! /bin/bash
# This is a list of toolchain-dependent configs. That is: only those which
# change .config when gcc, ld, or similar changes.
#
# please keep them sorted alphabetically
declare -a IGNORED_CONFIGS_RE=(
'AS_HAS_[A-Z0-9_]*'
'AS_VERSION'
'AS_WRUSS' # x86_32
'BUILTIN_RETURN_ADDRESS_STRIPS_PAC'
'CC_CAN_[A-Z_]*'
'CC_HAS_[A-Z_]*'
'CC_HAVE_[A-Z_]*'
'CC_VERSION_TEXT'
'DYNAMIC_SIGFRAME'
'FTRACE_MCOUNT_USE_[A-Z_]*'
'GCC_ASM_GOTO_OUTPUT_WORKAROUND'
'GCC_VERSION'
'G*CC[0-9]*_NO_[A-Z_]*'
'HAVE_[A-Z]*_COMPILER'
'HAVE_SHADOW_CALL_STACK'
'LD_VERSION'
'OBJTOOL'
'PAHOLE_HAS_[A-Z0-9_]*'
'PAHOLE_VERSION'
'RISCV_ISA_[A-Z_]*'
'TOOLCHAIN_HAS_[A-Z_]*'
'TOOLCHAIN_NEEDS_[A-Z_]*'
'TOOLS_SUPPORT_[A-Z_]*'
)
declare -a SED_ARGS=()
for CONFIG in "${IGNORED_CONFIGS_RE[@]}"; do
SED_ARGS+=(-e "/\\<CONFIG_$CONFIG\\>/ d")
done
SED_ARGS+=(
-e '/^# .* is not set$/p'
-e '/^$\|^#/d'
)
differences="$(
diff -bU0 <(sed "${SED_ARGS[@]}" "$1" | sort) \
<(sed "${SED_ARGS[@]}" "$2" | sort) \
| grep '^[-+][^-+]'
)" || true
if [ -n "$differences" ]; then
echo
echo "Changes after running \`make oldconfig':"
echo "$differences"
echo
if echo "$differences" | grep -q '^+' ; then
exit 1
fi
fi

13
check-module-license Normal file
View File

@ -0,0 +1,13 @@
#!/bin/sh
rc=0
for file in $(find "$@" -name '*.ko' -o -name '*.ko.xz' \
-o -name '*.ko.gz' -o -name '*.ko.zst'); do
l=$(/sbin/modinfo -F license "$file")
if [ -z "$l" ]; then
echo "ERROR: No license is included for module ${file##*/lib/modules/}"
rc=1
fi
done
exit $rc

15
compress-vmlinux.sh Normal file
View File

@ -0,0 +1,15 @@
#!/bin/bash
set -x
# Once the brp script is reasonably widespread, we will remove the specfile
# hack and this script
if test -x /usr/lib/rpm/brp-suse.d/brp-99-compress-vmlinux; then
exit 0
fi
vmlinux=$1
if test -e "$vmlinux" -a -e "$vmlinux.gz"; then
# Deliberately not using gzip -n; the vmlinux image has a predictable
# timestamp (bnc#880848#c20)
gzip -k -9 -f "$vmlinux"
fi

77
compute-PATCHVERSION.sh Normal file
View File

@ -0,0 +1,77 @@
#! /bin/bash
export LANG=POSIX
path=(.)
while test $# -gt 0; do
case "$1" in
--patches)
path[${#path[@]}]=$2
shift 2
;;
*)
echo "Usage $0 [--patches <dir>]" >&2
exit 1
esac
done
if test "${path[*]}" = "."; then
path=(. ..)
fi
source $(dirname $0)/config.sh
parse_srcversion()
{
local IFS=.
set -- ${SRCVERSION%%-*}
VERSION=$1
PATCHLEVEL=${2:-0}
SUBLEVEL=${3:-0}
EXTRAVERSION=${SRCVERSION#${SRCVERSION%%-*}}
}
parse_srcversion
EXTRA_SYMBOLS=$(set -- $([ -e $(dirname $0)/extra-symbols ] && cat $(dirname $0)/extra-symbols) ; echo $*)
series=$(mktemp)
tmp_files="$series"
trap 'rm -rf $tmp_files' EXIT
warned=false
while read patch; do
dir=${patch%/*}
for p in "${path[@]}"; do
if test -e "$p/$patch"; then
echo "$p/$patch"
continue 2
fi
done
for p in "${path[@]}"; do
if test -e "$p/$dir.tar.bz2"; then
echo "unpacking $p/$dir.tar.bz2" >&2
if ! $warned; then
echo "pass --patches <directory with unpacked tarballs> to avoid this" >&2
warned=true
fi
tmp_files="$tmp_files $dir"
tar -xjf "$p/$dir.tar.bz2"
echo "$patch"
continue 2
fi
done
echo "Can't find $patch" >&2
exit 1
done >"$series" < <($(dirname $0)/guards $EXTRA_SYMBOLS <series.conf)
# Parse all the changes to KERNELRELEASE out of all patches and
# convert them to shell code that can be evaluated. Evaluate it.
eval "$( {
<"$series" xargs awk '
/^--- |^\+\+\+ / \
{ M = match($2, /^[^\/]+\/Makefile( \t|$)/) }
M && /^+(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION)/ \
{ print }
' || echo exit 1 ; } \
| sed -e 's,^+,,' -e 's, *= *\(.*\),="\1",'
)"
echo "$VERSION.$PATCHLEVEL.$SUBLEVEL$EXTRAVERSION"

BIN
config.addon.tar.bz2 (Stored with Git LFS) Normal file
View File

Binary file not shown.

16
config.conf Normal file
View File

@ -0,0 +1,16 @@
# Kernel configuration file selection.
# See the arch-symbols script for a list of symbols defined.
# -syms excludes a flavor from the kernel-syms package (vanilla is excluded
# automatically).
#
# IMPORTANT: the subdirectory names map to cpuarch
# kernel-binary and kernel-source rely on this
#
+x86_64 x86_64/rt
+x86_64 -syms x86_64/rt_debug
# Prototype arm64 architecture for building test images
+arm64 arm64/rt
+arm64 -syms arm64/rt_debug

26
config.sh Normal file
View File

@ -0,0 +1,26 @@
# The version of the main tarball to use
SRCVERSION=6.4
# variant of the kernel-source package, either empty or "-rt"
VARIANT=-rt
# enable kernel module compression
COMPRESS_MODULES="zstd"
COMPRESS_VMLINUX="xz"
# Compile binary devicetrees on master and stable branches.
BUILD_DTBS="Yes"
# Generate a _multibuild file
MULTIBUILD="Yes"
# Use new style livepatch package names
LIVEPATCH=livepatch
# buildservice projects to build the kernel against
OBS_PROJECT=SUSE:ALP:Source:Standard:Core:1.0:Build
OBS_PROJECT_ARM=openSUSE:Factory:ARM
IBS_PROJECT=SUSE:ALP:Source:Standard:Core:1.0:Build
# Bugzilla info
BUGZILLA_SERVER="apibugzilla.suse.com"
BUGZILLA_PRODUCT="ALP"
SPLIT_OPTIONAL=No
SUPPORTED_MODULES_CHECK=Yes
# build documentation in HTML format
BUILD_HTML=Yes
# build documentation in PDF format
BUILD_PDF=No

BIN
config.tar.bz2 (Stored with Git LFS) Normal file
View File

Binary file not shown.

196
constraints.in Normal file
View File

@ -0,0 +1,196 @@
<constraints>
<!-- Default 35GB for binary packages -->
<overwrite>
<conditions>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<disk>
<size unit="G">35</size>
</disk>
<memory>
<size unit="G">4</size>
</memory>
</hardware>
</overwrite>
<!-- 8GB RAM for kernel-syzkaller -->
<overwrite>
<conditions>
<package>kernel-syzkaller</package>
<package>kernel-source@VARIANT@:kernel-syzkaller</package>
</conditions>
<hardware>
<physicalmemory>
<size unit="G">8</size>
</physicalmemory>
</hardware>
</overwrite>
<!-- 8GB for kernel-source@VARIANT@ -->
<overwrite>
<conditions>
<package>kernel-source@VARIANT@</package>
</conditions>
<hardware>
<disk>
<size unit="G">8</size>
</disk>
</hardware>
<hostlabel exclude="true">SLOW_DISK</hostlabel>
</overwrite>
<!-- 4GB for kernel-docs@VARIANT@ -->
<overwrite>
<conditions>
<package>kernel-docs@VARIANT@</package>
<package>kernel-source@VARIANT@:kernel-docs@VARIANT@</package>
</conditions>
<hardware>
<physicalmemory>
<size unit="G">4</size>
</physicalmemory>
</hardware>
</overwrite>
<!-- 24GB for binary packages on armv6/7 -->
<overwrite>
<conditions>
<arch>armv7l</arch>
<arch>armv6l</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<disk>
<size unit="G">24</size>
</disk>
</hardware>
</overwrite>
<!-- 16GB of disk and 2GB of memory for binary package on s390x -->
<overwrite>
<conditions>
<arch>s390x</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<disk>
<size unit="G">16</size>
</disk>
<memory>
<size unit="G">2</size>
</memory>
</hardware>
</overwrite>
<!-- 8 CPUs for binary packages on x86 -->
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<arch>riscv64</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<jobs>8</jobs>
</hardware>
</overwrite>
<!-- 4 CPUs for binary packages on POWER -->
<overwrite>
<conditions>
<arch>ppc</arch>
<arch>ppc64</arch>
<arch>ppc64le</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<jobs>4</jobs>
</hardware>
</overwrite>
<!-- 2 CPUs for binary packages on ARM -->
<overwrite>
<conditions>
<arch>aarch64</arch>
<arch>armv6l</arch>
<arch>armv7l</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<jobs>2</jobs>
</hardware>
</overwrite>
<!-- POWER9 now required on ppc64le -->
<overwrite>
<conditions>
<arch>ppc64le</arch>
</conditions>
<hardware>
<cpu>
<flag>power9</flag>
</cpu>
</hardware>
</overwrite>
<!-- Build on recent ARMv8.1 to avoid slow builders -->
<overwrite>
<conditions>
<arch>aarch64</arch>
</conditions>
<hardware>
<cpu>
<flag>asimdrdm</flag>
</cpu>
</hardware>
</overwrite>
<!-- 45GB for binary packages on aarch64 and x86-->
<overwrite>
<conditions>
<arch>aarch64</arch>
<arch>x86_64</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<disk>
<size unit="G">45</size>
</disk>
</hardware>
</overwrite>
<!-- 52GB for binary packages on riscv64-->
<overwrite>
<conditions>
<arch>riscv64</arch>
@BINARY_PACKAGES_XML@
</conditions>
<hardware>
<disk>
<size unit="G">52</size>
</disk>
</hardware>
</overwrite>
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<package>kernel-obs-qa</package>
<package>kernel-source@VARIANT@:kernel-obs-qa</package>
</conditions>
<sandbox>kvm</sandbox>
</overwrite>
<overwrite>
<conditions>
<arch>i586</arch>
<arch>x86_64</arch>
<package>kernel-obs-qa-xen</package>
<package>kernel-source@VARIANT@:kernel-obs-qa-xen</package>
</conditions>
<sandbox>xen</sandbox>
</overwrite>
</constraints>

104
dtb.spec.in.in Normal file
View File

@ -0,0 +1,104 @@
#
# spec file for package $NAME
#
# Copyright (c) @YEAR@ SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.
# Please submit bugfixes or comments via https://bugs.opensuse.org/
#
%define srcversion @SRCVERSION@
%define patchversion @PATCHVERSION@
%define variant @VARIANT@%{nil}
%include %_sourcedir/kernel-spec-macros
%(chmod +x %_sourcedir/{@SCRIPTS@})
Name: $NAME
Version: @RPMVERSION@
%if 0%{?is_kotd}
Release: <RELEASE>.g@COMMIT@
%else
Release: @RELEASE@
%endif
Summary: Device Tree files for $MACHINES
License: GPL-2.0-only
Group: System/Boot
URL: https://www.kernel.org/
BuildRequires: cpp
BuildRequires: dtc >= 1.4.3
BuildRequires: xz
%if ! 0%{?is_kotd} || ! %{?is_kotd_qa}%{!?is_kotd_qa:0}
$ARCH_RESTRICTIONS
%else
ExclusiveArch: do_not_build
%endif
%define dtbdir /boot/dtb-%kernelrelease
@SOURCES@
Requires: kernel = %version
%description
Device Tree files for $MACHINES.
$SUBPKG_DESC
%prep
# Unpack all sources and patches
%setup -q -c -T -a 0 @UNPACK_PATCHES@
cd linux-%srcversion
%_sourcedir/apply-patches %_sourcedir/series.conf ..
%build
source=linux-%srcversion
cp $source/COPYING .
SRCDIR=$PWD/$source
mkdir pp
PPDIR=$PWD/pp
export DTC_FLAGS="-R 4 -p 0x1000"
DTC_FLAGS="$DTC_FLAGS -@"
cd $source/$DTS_folder
for dts in $ALL_SUPPORTED_DTB; do
target=${dts%*.dts}
mkdir -p $PPDIR/$(dirname $target)
cpp -x assembler-with-cpp -undef -D__DTS__ -nostdinc -I. -I$SRCDIR/include/ -I$SRCDIR/scripts/dtc/include-prefixes/ -P $target.dts -o $PPDIR/$target.dts
dtc $DTC_FLAGS -I dts -O dtb -i ./$(dirname $target) -o $PPDIR/$target.dtb $PPDIR/$target.dts
done
%install
cd pp
for dts in $ALL_SUPPORTED_DTB; do
target=${dts%*.dts}
install -m 755 -d %{buildroot}%{dtbdir}/$(dirname $target)
# install -m 644 COPYING %{buildroot}%{dtbdir}/$(dirname $target)
install -m 644 $target.dtb %{buildroot}%{dtbdir}/$(dirname $target)
%ifarch %arm aarch64 riscv64
# HACK: work around U-Boot ignoring vendor dir
baselink=%{dtbdir}/$(basename $target).dtb
ln -s $target.dtb %{buildroot}$baselink
%ifarch %arm
case $dts in
$SUBPKG_CASE
esac
echo $baselink >> ../$pkgname.list
%else
vendordir=$(basename $(dirname $target))
echo $baselink >> ../dtb-$vendordir.list
%endif
%endif
done
cd -
%changelog

113
group-source-files.pl Normal file
View File

@ -0,0 +1,113 @@
#!/usr/bin/perl
use File::Spec;
use Getopt::Long;
use strict;
&main();
sub main
{
my($dev_output, $ndev_output, $loc) = ("-", "-", ".");
&Getopt::Long::Configure(qw(bundling));
&GetOptions(
"D=s" => \$dev_output,
"N=s" => \$ndev_output,
"L=s" => \$loc,
);
my($dev, $ndev) = &scan($loc);
&output($dev, $ndev, $dev_output, $ndev_output);
}
sub rpm_quote_filename
{
# technically should also quote % -> %% " -> \" \ -> \\
return map { "\"$_\"" } @_;
}
sub scan
{
# Normalize file path, mainly to strip away the ending forward slash,
# or any double forward slashes.
my $loc = File::Spec->canonpath(shift @_);
# We cannot use an absolute path (e.g. /usr/src/linux-5.14.21-150500.41)
# during find because it's under build root, but rpm wants one later.
my $abs_loc = rpm_path($loc);
my(@dev, @ndev);
foreach $_ (`find "$loc"`)
{
chomp $_;
if (-d $_ && !-l $_) {
# Generate directory list later.
next;
}
my $is_devel =
m{^\Q$loc\E.*/Kconfig} ||
m{^\Q$loc\E.*/Kbuild} ||
m{^\Q$loc\E.*/Makefile} ||
m{^\Q$loc\E/arch/[^/]+/boot/dts/include/dt-bindings\b} ||
m{^\Q$loc\E/arch/[^/]+/include\b} ||
m{^\Q$loc\E/arch/.*/module\.lds\b} ||
m{^\Q$loc\E/arch/arm/[^/]+/include/mach\b} ||
m{^\Q$loc\E/arch/arm/[^/]+/include/plat\b} ||
m{^\Q$loc\E/arch/[^/]+/scripts\b} ||
m{^\Q$loc\E/arch/[^/]+/tools\b} ||
m{^\Q$loc\E/include/[^/]+\b} ||
m{^\Q$loc\E/scripts\b};
my $abs_path = rpm_path($_);
$is_devel ? push(@dev, $abs_path) : push(@ndev, $abs_path);
}
my @dev_dirs = calc_dirs($abs_loc, \@dev);
my @ndev_dirs = calc_dirs($abs_loc, \@ndev);
@dev = rpm_quote_filename(@dev);
@ndev = rpm_quote_filename(@ndev);
@dev_dirs = map { "\%dir $_" } rpm_quote_filename(@dev_dirs);
@ndev_dirs = map { "\%dir $_" } rpm_quote_filename(@ndev_dirs);
push(@dev, @dev_dirs);
push(@ndev, @ndev_dirs);
return (\@dev, \@ndev);
}
sub calc_dirs
{
my($base, $files) = @_;
my %dirs;
foreach my $file (@$files) {
my ($volume,$path,$basename) = File::Spec->splitpath($file);
my @dirs = File::Spec->splitdir($path);
do {
# Always create $path from catdir() to avoid ending forward slash
$path = File::Spec->catdir(@dirs);
$dirs{$path} = 1;
pop @dirs;
} while ($path ne $base);
# This loop also makes sure that $base itself is included.
}
return keys %dirs;
}
sub output
{
my($dev, $ndev, $dev_out, $ndev_out) = @_;