Sync from SUSE:SLFO:Main kernel-source-rt revision 2df16d0184121ab07081e9ca44e4b094
This commit is contained in:
commit
865fc6e9f8
23
.gitattributes
vendored
Normal file
23
.gitattributes
vendored
Normal 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
6
README.KSYMS
Normal 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
316
README.PATCH-POLICY.SUSE
Normal 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
434
README.SUSE
Normal 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
220
_constraints
Normal 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
5
_multibuild
Normal 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
47
apply-patches
Normal 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
47
arch-symbols
Normal 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
57
check-for-config-changes
Normal 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
13
check-module-license
Normal 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
15
compress-vmlinux.sh
Normal 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
77
compute-PATCHVERSION.sh
Normal 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
BIN
config.addon.tar.bz2
(Stored with Git LFS)
Normal file
Binary file not shown.
16
config.conf
Normal file
16
config.conf
Normal 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
26
config.sh
Normal 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
BIN
config.tar.bz2
(Stored with Git LFS)
Normal file
Binary file not shown.
196
constraints.in
Normal file
196
constraints.in
Normal 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
104
dtb.spec.in.in
Normal 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
113
group-source-files.pl
Normal 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) = @_;
|