fedora 14 kernel performance with ip forwarding workload
by Jesse Brandeburg
The other day I was running the stock fedora kernel on my ip
forwarding setup, to see what the performance was, and the performance
wasn't very good.
system is S5520HC dual socket 2.93GHz Xeon 5570 (Nehalem) with 3 quad
port 82580 adapters (12 ports). Traffic is bidirectional 64 byte
packets being forwarded and received on each port, basically port to
port routing. I am only using 12 flows currently.
The driver is igb, and I am using an affinity script that lines up
each pair of ports that are forwarding traffic into optimal
configurations for cache locality. I am also disabling
remote_node_defrag_ratio to stop cross node traffic.
With the fedora default kernel from F14 it appears that
CONFIG_NETFILTER=y means that I cannot unload all of netfilter even if
I stop iptables service.
perf showed netfilter being prominent, and removing it gives me much
higher throughput. Is there a reason CONFIG_NETFILTER=y ? Isn't it a
good thing to be able to disable netfilter if you want to?
Jesse
8 years, 10 months
config-armv7-generic: USB_G_DBGP_PRINTK and USB_G_DBGP_SERIAL
by Paul Bolle
0) Building an rpm for (vanilla) v3.14, using the origin/f20 branch of
kernel.git, triggers a warning (a couple of times):
.config:5466:warning: override: USB_G_DBGP_SERIAL changes choice state
1) It turns out config-armv7-generic contains both
CONFIG_USB_G_DBGP_PRINTK=y
and
CONFIG_USB_G_DBGP_SERIAL=y
2) But in drivers/usb/gadget/Kconfig we see (summarized):
choice
prompt "EHCI Debug Device mode"
default USB_G_DBGP_SERIAL
config USB_G_DBGP_PRINTK
bool "printk"
config USB_G_DBGP_SERIAL
bool "serial"
endchoice
If I'm reading this correctly, this means that we need to choose between
USB_G_DBGP_PRINTK and USB_G_DBGP_PRINTK.
3) Should we remove one of these two Kconfig macros? Or is the upstream
Kconfig file incorrect and can both symbols be set simultaneously?
Paul Bolle
10 years
Feb. Fedora Kernel Patch Report
by Josh Boyer
It's been a while since I sent one of these. Mostly that's due to the
overlap between which upstream stable version we're using in Fedora
across the releases, and how fast those have been happening upstream.
We're settled on 3.13.y now, and with 3.14-rc4 out there things have
calmed down enough to take stock again.
Here's the patches we have on top of 3.13.5.
josh
fs-proc-devtree-remove_proc_entry.patch
- Upstream commit c1d867a54d426b45da017fbe8e585f8a3064ce8d
drm-radeon-Disable-writeback-by-default-on-ppc.patch
- This is superseded by upstream commit
ea31bf697d27270188a93cd78cf9de4bc968aca3 but that seems to be a bit
big for a stable backport
dm-cache-policy-mq_fix-large-scale-table-allocation-bug.patch (rhbz 993744)
- Still pending upstream (no idea why...)
sunrpc-create-a-new-dummy-pipe-for-gssd-to-hold-open.patch
sunrpc-replace-gssd_running-with-more-reliable-check.patch
nfs-check-gssd-running-before-krb5i-auth.patch
- Added to fix a 15sec mount delay
- Upstream commits 4b9a445e3eeb8bd9278b1ae51c1b3a651e370cd6
89f842435c630f8426f414e6030bc2ffea0d6f81
6aa23d76a7b549521a03b63b6d5b7880ea87eab7 respectively
rpc_pipe-remove-the-clntXX-dir-if-creating-the-pipe-fails.patch
sunrpc-add-an-info-file-for-the-dummy-gssd-pipe.patch
rpc_pipe-fix-cleanup-of-dummy-gssd-directory-when-notification-fails.patch
- Fixes for some of the patches above (rhbz 1037793)
- Upstream commits 3396f92f8be606ea485b0a82d4e7749a448b013b
e2f0c83a9de331d9352185ca3642616c13127539
23e66ba97127ff3b064d4c6c5138aa34eafc492f respectively
elantech-Properly-differentiate-between-clickpads-an.patch (rhbz 1030802)
- Upstream commit c15bdfd5b9831e4cab8cfc118243956e267dd30e
KVM-MMU-handle-invalid-root_hpa-at-__direct_map.patch (rhbz 924916)
- Upstream commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9
- Probably should grab 37f6a4e237303549c8676dfe1fd1991ceab512eb too
KVM-VMX-fix-use-after-free-of-vmx-loaded_vmcs.patch (rhbz 1047892)
- Upstream commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56
0001-Input-wacom-make-sure-touch_max-is-set-for-touch-dev.patch
0002-Input-wacom-add-support-for-three-new-Intuos-devices.patch
0003-Input-wacom-add-reporting-of-SW_MUTE_DEVICE-events.patch
- rhbz 1003167 1046238
- Upstream commits 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4
b5fd2a3e92ca5c8c1f3c20d31ac5daed3ec4d604
961794a00eab03f4344b7d5e825e8e789e55da87
Input-ALPS-add-support-for-Dolphin-devices.patch (rhbz 953211)
- Upstream commit ee65d4b36de8ddf4467f788faa5d8ddd1bfcdaa2
xhci-fix-resume-issues-on-renesas-chips-in-samsung-laptops.patch (rhbz 950630)
- Upstream commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d
- Oddly not queued for stable?
cgroup-fixes.patch (rhbz 1045755)
- Upstream commits 0ab02ca8f887908152d1a96db5130fc661d36a1e
- There was a 3.12 version of this patch sent to stable list from
Michal Hocko. I don't remember why it wasn't applied, or why it
wasn't applied for 3.13.y...
ipv6-introduce-IFA_F_NOPREFIXROUTE-and-IFA_F_MANAGETEMPADDR-flags.patch
ipv6-addrconf-revert-if_inet6ifa_flag-format.patch
- rhbz 1064430 1056711
- Backports of commits to add this stuff in 3.14. Not suitable for stable.
cifs-ensure-that-uncached-writes-handle-unmapped-areas-correctly.patch
cifs-sanity-check-length-of-data-to-send-before-sending.patch
cifs-mask-off-top-byte-in-get_rfc1002_length.patch
- rhbz 1064253 CVE-2014-0069 rhbz 1068862
- Upstream commit 5d81de8e8667da7135d3a32a964087c0faf5483f and two
additional fixes
cpufreq-powernow-k8-Initialize-per-cpu-data-structures-properly.patch
(rhbz 1054408)
- Upstream commit c3274763bfc3bf1ececa269ed6e6c4d7ec1c3e5e
- CC'd to stable but not queued
e100-Fix-disabling-already-disabled-device-warning.patch (rhbz 994438)
- Upstream commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4
usb-ehci-fix-deadlock-when-threadirqs-option-is-used.patch
- Still pending upstream
10 years
Where do rcX-gitY patches come from?
by Josh Stone
I know there used to be a linux-2.6-snaps.git tree that had rcX-gitY
tags, but I haven't seen that in a while, I think since the kernel.org
rebuild. Yet rawhide still uses patches of this form. Is there a git
tree where these are maintained?
10 years
does zram in fedora need any configuration
by Reindl Harald
Hi
since 3.14 is not that far away zram becomes interesting
the article below maybe outdated, on a rawhide-VM exists
/dev/zram0 as well as a implicit systemd-unit, well
does that mean it is automagically configured and if
that is the case does systemd < 212 that also or is
there handwork needed for the time F19/F20 get rebased
to kernel 3.14?
[root@rawhide ~]# systemctl list-units | grep zram
sys-devices-virtual-block-zram0.device loaded active plugged /sys/devices/virtual/block/zram0
http://mystilleef.blogspot.co.at/2011/10/enable-zram-in-fedora.html
10 years, 1 month
What is the plan for rawhide and 3.15 ?
by Hans de Goede
Hi,
I was wondering what the plan is wrt rawhide and 3.15, will rawhide move to
3.15-rc1 once it is available or is the plan to stabilize at 3.14 ?
I'm asking because of:
https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport
I've been putting a lot of time getting as much sunxi code upstream as
possible, and I'm about ready to start preparing a patch-set to add
to the Fedora kernels for now. But if we're going to move to 3.15, then
my time is better spend elsewhere until 3.15-rc1 hits rawhide.
Thanks & Regards,
Hans
10 years, 1 month
March Fedora kernel release overview
by Josh Boyer
Hi All,
A brief overview of where things stand in terms of the kernel on each
release. I promised I was going to send this out in place of the
Fedora kernel IRC meetings. If there are other topics/questions you
have, please just reply and ask away!
F19/F20:
Currently at 3.13.6 with nothing pending in updates-testing. These
will get 3.13.7 bumps in updates-testing early next week.
With the 3.13 rebase for F19, we also switched over the Secure Boot
patchset to match that in F20. That means we have one patchset to
maintain, and no release is stuck with the old (and somewhat broken)
capabilities approach. This should not impact anyone and I would be
surprised if anyone noticed.
Rawhide (F21):
Currently at 3.14-rc7.git2 and will likely move to 3.14 final early
next week. I'll leave it at 3.14 final for a couple of days, and then
progress to the 3.15 merge window kernels thereafter. Business as
usual.
In terms of F21 and which kernel we'll ship with, we're in a similar
situation as we were with F20. The current F21 release date is
mid-October. Using http://phb-crystal-ball.org/ (which is fairly
accurate), we'll likely be approaching the release of 3.17 around that
timeframe. However, squeezing it in at the last minute is generally a
bad idea so we will likely be shipping the 3.16 kernel with F21 at GA.
This is clearly not set in stone, but it's the best estimate we have
at the moment.
Fedora.next kernel packaging changes:
As seen on-list, I'm working on splitting up the kernel packaging to
make a kernel-core/kernel-drivers split that the Cloud people can use.
I should be ready to post RFC patches next week, but more testing on
the existing COPR would be appreciated:
http://copr-fe.cloud.fedoraproject.org/coprs/jwboyer/kernel-core/
Thanks, and as mentioned above, please don't hesitate to ask questions.
josh
10 years, 1 month
[WIP] Create kernel-core and kernel-drivers subpackages
by Josh Boyer
There are still some things I need to fix before this is really ready,
but in the spirit of release-early here is the current kernel.spec file
diff I have. This does a few things.
Macros and %files:
1) Moves the kernel_reqprovconf macro down a bit and makes the plain
"kernel" package a meta-package
2) All actual kernel builds are now done via the kernel_variant_package
macro. If no variant is given, it builds kernel-core. Otherwise it
builds kernel-<variant>-core.
3) Adds a kernel_drivers_package subpackage macro that
kernel_variant_package expands and includes. Also defines the proper
post and postun scriptlets.
4) Makes the kernel_variant_files macro use file lists for the
kernel-core and kernel-drivers subpackages.
File list generation:
The hunk in the middle is what generates the file lists that item 4
above uses. It does
1) calls a script called "filter_modules" that goes through and removes
the modules we don't consider important enough to be in kernel-core in
the RPM_BUILD_DIR.
2) calls depmod on the now filtered tree, as kernel-core should be
self-contained.
3) Restores the module directory from a copy we've made prior, so that
RPM can do it's package assembly later.
4) Save off the file lists in the proper location for later use and
cleanup.
TODO:
Right now this is what has been building in my COPR for the past week.
It works well on x86_64 (which is all I've tested), and i686 builds but
I know it's broken on ARM. To finish it up, I need:
1) Review from you all.
2) A per-arch filter list, because the existing one that works on
x86_64 leaves modules in kernel-core on ARM that lack their
dependencies. Bad.
3) Further testing on all arches.
4) To make the depmod call fatal to the build. Without making this
fatal we run the risk of pushing kernel-core packages that aren't
self-contained and that seems pretty bad to me. It shouldn't be a huge
issue as I would think most of the breakage is going to come from merge
window stuff and settle down after that.
josh
diff --git a/kernel.spec b/kernel.spec
index e055bb2..4ffa1b6 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -34,7 +34,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
-%global baserelease 1
+%global baserelease 8
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@@ -385,29 +385,6 @@ Summary: The Linux kernel
%define kernel_prereq fileutils, systemd >= 203-2
%define initrd_prereq dracut >= 027
-#
-# This macro does requires, provides, conflicts, obsoletes for a kernel package.
-# %%kernel_reqprovconf <subpackage>
-# It uses any kernel_<subpackage>_conflicts and kernel_<subpackage>_obsoletes
-# macros defined above.
-#
-%define kernel_reqprovconf \
-Provides: kernel = %{rpmversion}-%{pkg_release}\
-Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}%{?1:+%{1}}\
-Provides: kernel-drm-nouveau = 16\
-Provides: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
-Requires(pre): %{kernel_prereq}\
-Requires(pre): %{initrd_prereq}\
-Requires(pre): linux-firmware >= 20130724-29.git31f6b30\
-Requires(preun): systemd >= 200\
-%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\
-%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}\
-%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}\
-# We can't let RPM do the dependencies automatic because it'll then pick up\
-# a correct but undesirable perl dependency from the module headers which\
-# isn't required for the kernel proper to function\
-AutoReqProv: no\
-%{nil}
Name: kernel%{?variant}
Group: System Environment/Kernel
@@ -419,8 +396,9 @@ Release: %{pkg_release}
# SET %%nobuildarches (ABOVE) INSTEAD
ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ppc64p7 s390 s390x %{arm} aarch64 ppc64le
ExclusiveOS: Linux
+Requires: kernel-%{?variant:%{variant}-}core-uname-r = %{KVERREL}%{?variant}
+Requires: kernel-%{?variant:%{variant}-}drivers-uname-r = %{KVERREL}%{?variant}
-%kernel_reqprovconf
#
# List the packages used during the kernel build
@@ -464,6 +442,7 @@ Source15: merge.pl
Source16: mod-extra.list
Source17: mod-extra.sh
Source18: mod-sign.sh
+Source99: filter-modules.sh
%define modsign_cmd %{SOURCE18}
Source19: Makefile.release
@@ -649,10 +628,31 @@ Patch25044: iwlwifi-dvm-take-mutex-when-sending-SYNC-BT-config-command.patch
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
%description
-The kernel package contains the Linux kernel (vmlinuz), the core of any
-Linux operating system. The kernel handles the basic functions
-of the operating system: memory allocation, process allocation, device
-input and output, etc.
+The kernel meta package
+
+#
+# This macro does requires, provides, conflicts, obsoletes for a kernel package.
+# %%kernel_reqprovconf <subpackage>
+# It uses any kernel_<subpackage>_conflicts and kernel_<subpackage>_obsoletes
+# macros defined above.
+#
+%define kernel_reqprovconf \
+Provides: kernel = %{rpmversion}-%{pkg_release}\
+Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}%{?1:+%{1}}\
+Provides: kernel-drm-nouveau = 16\
+Provides: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires(pre): %{kernel_prereq}\
+Requires(pre): %{initrd_prereq}\
+Requires(pre): linux-firmware >= 20130724-29.git31f6b30\
+Requires(preun): systemd >= 200\
+%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\
+%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}\
+%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}\
+# We can't let RPM do the dependencies automatic because it'll then pick up\
+# a correct but undesirable perl dependency from the module headers which\
+# isn't required for the kernel proper to function\
+AutoReqProv: no\
+%{nil}
%package headers
Summary: Header files for the Linux kernel for use by glibc
@@ -834,53 +834,65 @@ Provides: kernel%{?1:-%{1}}-modules-extra = %{version}-%{release}%{?1:+%{1}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-extra-uname-r = %{KVERREL}%{?1:+%{1}}\
Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel-drivers-uname-r = %{KVERREL}%{?1:+%{1}}\
AutoReqProv: no\
%description -n kernel%{?variant}%{?1:-%{1}}-modules-extra\
This package provides less commonly used kernel modules for the %{?2:%{2} }kernel package.\
%{nil}
#
+# This macro creates a kernel-<subpackage>-drivers package.
+# %%kernel_drivers_package <subpackage> <pretty-name>
+#
+%define kernel_drivers_package() \
+%package %{?1:%{1}-}drivers\
+Summary: kernel modules to match the %{?2:%{2}-}core kernel\
+Group: System Environment/Kernel\
+Provides: kernel%{?1:-%{1}}-drivers-%{_target_cpu} = %{version}-%{release}\
+Provides: kernel-drivers-%{_target_cpu} = %{version}-%{release}%{?1:+%{1}}\
+Provides: kernel-drivers = %{version}-%{release}%{?1:+%{1}}\
+Provides: installonlypkg(kernel-module)\
+Provides: kernel-drivers-uname-r = %{KVERREL}%{?1:+%{1}}\
+Requires: kernel-uname-r = %{KVERREL}%{?1:+%{1}}\
+AutoReqProv: no\
+%description -n kernel%{?variant}%{?1:-%{1}}-drivers\
+This package provides commonly used kernel modules for the %{?2:%{2}-}core kernel package.\
+%{nil}
+
+#
# This macro creates a kernel-<subpackage> and its -devel and -debuginfo too.
# %%define variant_summary The Linux kernel compiled for <configuration>
# %%kernel_variant_package [-n <pretty-name>] <subpackage>
#
%define kernel_variant_package(n:) \
-%package %1\
+%package %{?1:%{1}-}core\
Summary: %{variant_summary}\
Group: System Environment/Kernel\
-%kernel_reqprovconf\
-%{expand:%%kernel_devel_package %1 %{!?-n:%1}%{?-n:%{-n*}}}\
+Provides: kernel-%{?1:%{1}-}core-uname-r = %{KVERREL}%{?1:+%{1}}\
+%{expand:%%kernel_reqprovconf}\
+%{expand:%%kernel_devel_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}}\
+%{expand:%%kernel_drivers_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}}\
%if %{with_extra}\
-%{expand:%%kernel_modules_extra_package %1 %{!?-n:%1}%{?-n:%{-n*}}}\
+%{expand:%%kernel_modules_extra_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}}\
%endif\
-%{expand:%%kernel_debuginfo_package %1}\
+%{expand:%%kernel_debuginfo_package %{?1:%{1}}}\
%{nil}
-
-# First the auxiliary packages of the main kernel package.
-%kernel_devel_package
-%if %{with_extra}
-%kernel_modules_extra_package
-%endif
-%kernel_debuginfo_package
-
-
# Now, each variant package.
%define variant_summary The Linux kernel compiled for SMP machines
%kernel_variant_package -n SMP smp
-%description smp
+%description smp-core
This package includes a SMP version of the Linux kernel. It is
required only on machines with two or more CPUs as well as machines with
hyperthreading technology.
Install the kernel-smp package if your machine uses two or more CPUs.
-
%ifnarch armv7hl
%define variant_summary The Linux kernel compiled for PAE capable machines
%kernel_variant_package %{pae}
-%description %{pae}
+%description %{pae}-core
This package includes a version of the Linux kernel with support for up to
64GB of high memory. It requires a CPU with Physical Address Extensions (PAE).
The non-PAE kernel can only address up to 4GB of memory.
@@ -888,7 +900,7 @@ Install the kernel-PAE package if your machine has more than 4GB of memory.
%else
%define variant_summary The Linux kernel compiled for Cortex-A15
%kernel_variant_package %{pae}
-%description %{pae}
+%description %{pae}-core
This package includes a version of the Linux kernel with support for
Cortex-A15 devices with LPAE and HW virtualisation support
%endif
@@ -897,7 +909,7 @@ Cortex-A15 devices with LPAE and HW virtualisation support
%define variant_summary The Linux kernel compiled with extra debugging enabled for PAE capable machines
%kernel_variant_package %{pae}debug
Obsoletes: kernel-PAE-debug
-%description %{pae}debug
+%description %{pae}debug-core
This package includes a version of the Linux kernel with support for up to
64GB of high memory. It requires a CPU with Physical Address Extensions (PAE).
The non-PAE kernel can only address up to 4GB of memory.
@@ -910,7 +922,7 @@ on kernel bugs, as some of these options impact performance noticably.
%define variant_summary The Linux kernel compiled with extra debugging enabled
%kernel_variant_package debug
-%description debug
+%description debug-core
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system. The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
@@ -920,6 +932,16 @@ This variant of the kernel has numerous debugging options enabled.
It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
+# And finally the main -core package
+
+%define variant_summary The Linux kernel
+%kernel_variant_package
+%description core
+The kernel package contains the Linux kernel (vmlinuz), the core of any
+Linux operating system. The kernel handles the basic functions
+of the operating system: memory allocation, process allocation, device
+input and output, etc.
+
%prep
# do a few sanity-checks for --with *only builds
@@ -1589,6 +1611,53 @@ BuildKernel() {
%{SOURCE17} $RPM_BUILD_ROOT/lib/modules/$KernelVer %{SOURCE16}
%endif
+ #
+ # Generate the kernel-core and kernel-drivers files lists
+ #
+
+ # Copy the System.map file for depmod to use, and create a backup of the
+ # full module tree so we can restore it after we're done filtering
+ cp System.map $RPM_BUILD_ROOT/.
+ pushd $RPM_BUILD_ROOT
+ mkdir restore
+ cp -r lib/modules/$KernelVer/* restore/.
+
+ # don't include anything going into k-m-e in the file lists
+ rm -rf lib/modules/$KernelVer/extra
+
+ # Find all the module files and filter them out into the core and drivers
+ # lists. This actually removes anything going into -drivers from the dir.
+ find lib/modules/$KernelVer/kernel -name *.ko | sort -n > modules.list
+ %{SOURCE99} modules.list
+
+ # Run depmod on the resulting module tree and make sure it isn't broken
+ depmod -b . -aeF ./System.map $KernelVer
+ # remove files that will be auto generated by depmod at rpm -i time
+ pushd $RPM_BUILD_ROOT/lib/modules/$KernelVer/
+ rm -f modules.{alias*,builtin.bin,dep*,*map,symbols*,devname,softdep}
+ popd
+
+ # Go back and find all of the various directories in the tree. We use this
+ # for the dir lists in kernel-core
+ find lib/modules/$KernelVer/kernel -type d | sort -n > module-dirs.list
+
+ # Cleanup
+ rm System.map
+ cp -r restore/* lib/modules/$KernelVer/.
+ rm -rf restore
+ popd
+
+ # Make sure the files lists start with absolute paths or rpmbuild fails.
+ # Also add in the dir entries
+ sed -e 's/^lib*/\/lib/' $RPM_BUILD_ROOT/k-d.list > ../kernel${Flavour:+-${Flavour}}-drivers.list
+ sed -e 's/^lib*/%dir \/lib/' $RPM_BUILD_ROOT/module-dirs.list > ../kernel${Flavour:+-${Flavour}}-core.list
+ sed -e 's/^lib*/\/lib/' $RPM_BUILD_ROOT/modules.list >> ../kernel${Flavour:+-${Flavour}}-core.list
+
+ # Cleanup
+ rm -f $RPM_BUILD_ROOT/k-d.list
+ rm -f $RPM_BUILD_ROOT/modules.list
+ rm -f $RPM_BUILD_ROOT/module-dirs.list
+
%if %{signmodules}
# Save the signing keys so we can sign the modules in __modsign_install_post
cp signing_key.priv signing_key.priv.sign${Flav}
@@ -1857,11 +1926,28 @@ fi\
#
# This macro defines a %%post script for a kernel*-modules-extra package.
+# It also defines a %%postun script that does the same thing.
# %%kernel_modules_extra_post [<subpackage>]
#
%define kernel_modules_extra_post() \
%{expand:%%post %{?1:%{1}-}modules-extra}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
+%{nil}\
+%{expand:%%postun %{?1:%{1}-}modules-extra}\
+/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
+%{nil}
+
+#
+# This macro defines a %%post script for a kernel*-drivers package.
+# It also defines a %%postun script that does the same thing.
+# %%kernel_drivers_post [<subpackage>]
+#
+%define kernel_drivers_post() \
+%{expand:%%post %{?1:%{1}-}drivers}\
+/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
+%{nil}\
+%{expand:%%postun %{?1:%{1}-}drivers}\
+/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}
# This macro defines a %%posttrans script for a kernel package.
@@ -1869,7 +1955,7 @@ fi\
# More text can follow to go at the end of this variant's %%post.
#
%define kernel_variant_posttrans() \
-%{expand:%%posttrans %{?1}}\
+%{expand:%%posttrans %{?1:%{1}-}core}\
/bin/kernel-install add %{KVERREL}%{?1:+%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:+%{1}} || exit $?\
%{nil}
@@ -1880,11 +1966,12 @@ fi\
#
%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
+%{expand:%%kernel_drivers_post %{?-v*}}\
%if %{with_extra}\
%{expand:%%kernel_modules_extra_post %{?-v*}}\
%endif\
%{expand:%%kernel_variant_posttrans %{?-v*}}\
-%{expand:%%post %{?-v*}}\
+%{expand:%%post %{?-v*:%{-v*}-}core}\
%{-r:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
[ -f /etc/sysconfig/kernel ]; then\
@@ -1897,7 +1984,7 @@ fi}\
# %%kernel_variant_preun <subpackage>
#
%define kernel_variant_preun() \
-%{expand:%%preun %{?1}}\
+%{expand:%%preun %{?1:%{1}-}core}\
/bin/kernel-install remove %{KVERREL}%{?1:+%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:+%{1}} || exit $?\
%{nil}
@@ -1998,6 +2085,10 @@ fi
%endif
%endif # with_perf
+# empty meta-package
+%files
+%defattr(-,root,root)
+
# This is %%{image_install_path} on an arch where that includes ELF files,
# or empty otherwise.
%define elf_image_install_path %{?kernel_image_elf:%{image_install_path}}
@@ -2009,7 +2100,7 @@ fi
#
%define kernel_variant_files(k:) \
%if %{1}\
-%{expand:%%files %{?2}}\
+%{expand:%%files -f kernel-%{?2:%{2}-}core.list %{?2:%{2}-}core}\
%defattr(-,root,root)\
/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2:+%{2}}\
/%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:+%{2}}.hmac \
@@ -2018,9 +2109,10 @@ fi
%endif\
%attr(600,root,root) /boot/System.map-%{KVERREL}%{?2:+%{2}}\
/boot/config-%{KVERREL}%{?2:+%{2}}\
+%ghost /boot/initramfs-%{KVERREL}%{?2:+%{2}}.img\
%dir /lib/modules\
%dir /lib/modules/%{KVERREL}%{?2:+%{2}}\
-/lib/modules/%{KVERREL}%{?2:+%{2}}/kernel\
+%dir /lib/modules/%{KVERREL}%{?2:+%{2}}/kernel\
/lib/modules/%{KVERREL}%{?2:+%{2}}/build\
/lib/modules/%{KVERREL}%{?2:+%{2}}/source\
/lib/modules/%{KVERREL}%{?2:+%{2}}/updates\
@@ -2029,7 +2121,8 @@ fi
/etc/ld.so.conf.d/kernel-%{KVERREL}%{?2:+%{2}}.conf\
%endif\
/lib/modules/%{KVERREL}%{?2:+%{2}}/modules.*\
-%ghost /boot/initramfs-%{KVERREL}%{?2:+%{2}}.img\
+%{expand:%%files -f kernel-%{?2:%{2}-}drivers.list %{?2:%{2}-}drivers}\
+%defattr(-,root,root)\
%{expand:%%files %{?2:%{2}-}devel}\
%defattr(-,root,root)\
/usr/src/kernels/%{KVERREL}%{?2:+%{2}}\
10 years, 1 month
kernel split up
by Josh Boyer
OK, initial builds of the packaging split I talked about last week are now at:
http://copr-fe.cloud.fedoraproject.org/coprs/jwboyer/kernel-core/
Feel free to poke around with the build from today in some VMs you
don't care about. I have installed the x86_64 kernel-core package on
a local VM and booted successfully. The split is roughly what I
talked about last week as well:
[jwboyer@vader kernel]$ rpm -qpi
x86_64/kernel-core-3.14.0-0.rc6.git2.4.fc21.x86_64.rpm | grep Size
Size : 77220258
[jwboyer@vader kernel]$ rpm -qpi
x86_64/kernel-drivers-3.14.0-0.rc6.git2.4.fc21.x86_64.rpm | grep Size
Size : 65418445
So ~74MB for kernel-core installed with a 17MB RPM size, and ~63MB for
kernel-drivers installed with a 16MB RPM size.
I'll be doing some more local testing of various things over the next
couple of days. Once I see that they aren't totally broken, I'll post
the patches to the kernel list.
josh
10 years, 1 month
