From roland at redhat.com Wed Aug 1 02:11:05 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 31 Jul 2007 19:11:05 -0700 (PDT) Subject: macrofied kernel.spec Message-ID: <20070801021105.19E144D04B9@magilla.localdomain> The patch below revamps kernel.spec using macros to minimize duplication. There is now very little boilerplate to write/update for each variant built. It's now just a few %kernel_variant_foo macro lines for each flavor (plus %description, which is unchanged). When the common boilerplate details change, there is just one place to go tweak the spec (in a macro definition) and no way to forget to update all the flavors. There was an earlier foray into fancy macro use in the kernel spec file, which got punted because of troubles with ancient rpmbuild versions. But that was then, and this is now. Since then, the build systems got fixed to use the proper rpmbuild for each build version, and anyway are no longer running on RHEL3. No living (or recently dead) Fedora, nor AFAIK RHEL>=4, will have problems with this spec file. The diff looks large, but that's because kernel.spec got ~500 lines shorter. Even with the sprinkling of %%-heavy magic in the macro definitions, I think the spec file is now overall easier to read. (I say this, but then, I wrote the glibc makefiles as a child, so my judgment is clearly suspect, and my breeding a lost cause.) I think this is a nice cleanup on its own. The reason I actually did it is that the debuginfo package details will have to change soon when a new find-debuginfo.sh comes in rpm, which is cleaned up generally and does new magic for the build-id stuff. I really don't want to have to start dicking with that before it's consolidated into only one place I have to touch. I've verified that this is a no-op vs the 0.61 build. i.e., it generates rpms with the same files and same rpm magic, modulo a few typo fixes and cosmetic cleanups/consolidation of rpm script fragments. In the absence of frothing vitriol, I will commit this after f8-test1 has sailed. Thanks, Roland --- kernel.spec.~1.44~ 2007-07-31 15:01:40.000000000 -0700 +++ kernel.spec 2007-07-31 17:44:57.000000000 -0700 @@ -363,6 +363,11 @@ Summary: The Linux kernel (the core of t %define _enable_debug_packages 0 %endif +%define with_pae_debug 0 +%if %with_pae +%define with_pae_debug %{with_debug} +%endif + # # Three sets of minimum package version requirements in the form of Conflicts: # to versions below the minimum @@ -385,7 +390,12 @@ Summary: The Linux kernel (the core of t # # The ld.so.conf.d file we install uses syntax older ldconfig's don't grok. # -%define xen_conflicts glibc < 2.3.5-1, xen < 3.0.1 +%define kernel_xen_conflicts glibc < 2.3.5-1, xen < 3.0.1 + +# upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called kernel-enterprise +# now that the smp kernel offers this capability, obsolete the old kernel +%define kernel_smp_obsoletes kernel-enterprise < 2.4.10 +%define kernel_PAE_obsoletes kernel-smp < 2.6.17 # # Packages that need to be installed before the kernel is, because the %post @@ -393,6 +403,29 @@ Summary: The Linux kernel (the core of t # %define kernel_prereq fileutils, module-init-tools, initscripts >= 8.11.1-1, mkinitrd >= 6.0.9-7 +# +# This macro does requires, provides, conflicts, obsoletes for a kernel package. +# %%kernel_reqprovconf +# It uses any kernel__conflicts and kernel__obsoletes +# macros defined above. +# +%define kernel_reqprovconf \ +Provides: kernel = %{rpmversion}-%{pkg_release}\ +Provides: kernel-%{_target_cpu} = %{rpmversion}-%{pkg_release}\ +Provides: kernel-drm = 4.3.0\ +Provides: kernel-drm-nouveau = 6\ +Requires(pre): %{kernel_prereq}\ +Conflicts: %{kernel_dot_org_conflicts}\ +Conflicts: %{package_conflicts}\ +%{?1:%{expand:%%{?kernel_%1_conflicts:Conflicts: %%{kernel_%1_conflicts}}}}\ +%{?1:%{expand:%%{?kernel_%1_obsoletes:Obsoletes: %%{kernel_%1_obsoletes}}}}\ +# 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\ +AutoReq: no\ +AutoProv: yes\ +%{nil} + Name: kernel%{?variant} Group: System Environment/Kernel License: GPLv2 @@ -403,17 +436,11 @@ Release: %{pkg_release} # SET %nobuildarches (ABOVE) INSTEAD ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56 ExclusiveOS: Linux -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release} -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -# 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 -AutoReq: no -AutoProv: yes + +%kernel_reqprovconf +%ifarch x86_64 +Obsoletes: kernel-smp +%endif # @@ -601,24 +628,37 @@ Patch1230: linux-2.6-powerpc-spu-vicinit BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root-%{_target_cpu} -%ifarch x86_64 -Obsoletes: kernel-smp -%endif - %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 +of the operating system: memory allocation, process allocation, device input and output, etc. -%package debuginfo -Summary: Debug information for package %{name} -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-debuginfo-%{_target_cpu} = %{KVERREL} -%description debuginfo -This package provides debug information for package %{name} -This is required to use SystemTap with %{name}-%{KVERREL}. + +%package doc +Summary: Various documentation bits found in the kernel source +Group: Documentation +%description doc +This package contains documentation files from the kernel +source. Various bits of information about the Linux kernel and the +device drivers shipped with it are documented in these files. + +You'll want to install this package if you need a reference to the +options that can be passed to Linux kernel modules at load time. + + +%package headers +Summary: Header files for the Linux kernel for use by glibc +Group: Development/System +Obsoletes: glibc-kernheaders +Provides: glibc-kernheaders = 3.0-46 +%description headers +Kernel-headers includes the C header files that specify the interface +between the Linux kernel and userspace libraries and programs. The +header files define structures and constants that are needed for +building most standard programs and are also needed for rebuilding the +glibc package. + %package debuginfo-common Summary: Kernel source files used by %{name}-debuginfo packages @@ -628,34 +668,64 @@ Provides: %{name}-debuginfo-common-%{_ta This package is required by %{name}-debuginfo subpackages. It provides the kernel source files common to all builds. -%package devel -Summary: Development package for building kernel modules to match the kernel. -Group: System Environment/Kernel -AutoReqProv: no -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release} -Requires(pre): /usr/bin/find -%description devel -This package provides kernel headers and makefiles sufficient to build modules -against the kernel package. -%package smp -Summary: The Linux kernel compiled for SMP machines. -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}smp -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -# upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called kernel-enterprise -# now that the smp kernel offers this capability, obsolete the old kernel -Obsoletes: kernel-enterprise < 2.4.10 -# 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 -AutoReq: no -AutoProv: yes +# +# This macro creates a kernel--debuginfo package. +# %%kernel_debuginfo_package +# +%define kernel_debuginfo_package() \ +%package %{?1:%{1}-}debuginfo\ +Summary: Debug information for package %{name}%{?1:-%{1}}\ +Group: Development/Debug\ +Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL}\ +Provides: %{name}%{?1:-%{1}}-debuginfo-%{_target_cpu} = %{KVERREL}\ +%description -n %{name}%{?1:-%{1}}-debuginfo\ +This package provides debug information for package %{name}%{?1:-%{1}}.\ +This is required to use SystemTap with %{name}%{?1:-%{1}}-%{KVERREL}.\ +%{nil} + +# +# This macro creates a kernel--devel package. +# %%kernel_devel_package +# +%define kernel_devel_package() \ +%package %{?1:%{1}-}devel\ +Summary: Development package for building kernel modules to match the %{?2:%{2} }kernel\ +Group: System Environment/Kernel\ +Provides: kernel%{?1:-%{1}}-devel-%{_target_cpu} = %{rpmversion}-%{release}\ +Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}%{?1}\ +Provides: kernel-devel = %{rpmversion}-%{release}%{?1}\ +AutoReqProv: no\ +Requires(pre): /usr/bin/find\ +%description -n kernel%{?variant}%{?1:-%{1}}-devel\ +This package provides kernel headers and makefiles sufficient to build modules\ +against the %{?2:%{2} }kernel package.\ +%{nil} + +# +# This macro creates a kernel- and its -devel and -debuginfo too. +# %%define variant_summary The Linux kernel compiled for +# %%kernel_variant_package [-n ] +# +%define kernel_variant_package(n:) \ +%package %1\ +Summary: %{variant_summary}\ +Group: System Environment/Kernel\ +%kernel_reqprovconf\ +%{expand:%%kernel_devel_package %1 %{!?-n:%1}%{?-n:%{-n*}}}\ +%{expand:%%kernel_debuginfo_package %1}\ +%{nil} + + +# First the auxiliary packages of the main kernel package. +%kernel_devel_package +%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 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 @@ -663,83 +733,18 @@ hyperthreading technology. Install the kernel-smp package if your machine uses two or more CPUs. -%package smp-debuginfo -Summary: Debug information for package %{name}-smp -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-%smp-debuginfo-%{_target_cpu} = %{KVERREL} -%description smp-debuginfo -This package provides debug information for package %{name}-smp -This is required to use SystemTap with %{name}-smp-%{KVERREL}. - -%package smp-devel -Summary: Development package for building kernel modules to match the SMP kernel. -Group: System Environment/Kernel -Provides: kernel-smp-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}smp -Provides: kernel-devel = %{rpmversion}-%{release}smp -AutoReqProv: no -Requires(pre): /usr/bin/find -%description smp-devel -This package provides kernel headers and makefiles sufficient to build modules -against the SMP kernel package. - -%package PAE -Summary: The Linux kernel compiled for PAE capable machines. -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}PAE -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -Obsoletes: kernel-smp < 2.6.17 -# 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 -AutoReq: no -AutoProv: yes +%define variant_summary The Linux kernel compiled for PAE capable machines +%kernel_variant_package PAE %description PAE 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. Install the kernel-PAE package if your machine has more than 4GB of memory. -%package PAE-debuginfo -Summary: Debug information for package %{name}-PAE -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-%PAE-debuginfo-%{_target_cpu} = %{KVERREL} -%description PAE-debuginfo -This package provides debug information for package %{name}-PAE -This is required to use SystemTap with %{name}-PAE-%{KVERREL}. - -%package PAE-devel -Summary: Development package for building kernel modules to match the PAE kernel. -Group: System Environment/Kernel -Provides: kernel-PAE-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}PAE -Provides: kernel-devel = %{rpmversion}-%{release}PAE -AutoReqProv: no -Requires(pre): /usr/bin/find -%description PAE-devel -This package provides kernel headers and makefiles sufficient to build modules -against the PAE kernel package. -%package PAE-debug -Summary: The Linux kernel compiled with extra debugging enabled for PAE capable machines. -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}PAE-debug -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -AutoReq: no -AutoProv: yes +%define variant_summary The Linux kernel compiled with extra debugging enabled for PAE capable machines +%kernel_variant_package PAE-debug %description PAE-debug 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). @@ -750,64 +755,9 @@ This variant of the kernel has numerous It should only be installed when trying to gather additional information on kernel bugs, as some of these options impact performance noticably. -%package PAE-debug-debuginfo -Summary: Debug information for package %{name}-PAE-debug -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-debug-debuginfo-%{_target_cpu} = %{KVERREL} -%description PAE-debug-debuginfo -This package provides debug information for package %{name}-PAE-debug - -%package PAE-debug-devel -Summary: Development package for building kernel modules to match the kernel. -Group: System Environment/Kernel -AutoReqProv: no -Requires(pre): /usr/bin/find -Provides: kernel-PAE-debug-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}PAE-debug -Provides: kernel-devel = %{rpmversion}-%{release}PAE-debug -%description PAE-debug-devel -This package provides kernel headers and makefiles sufficient to build modules -against the kernel package. - -%package doc -Summary: Various documentation bits found in the kernel source. -Group: Documentation -%description doc -This package contains documentation files from the kernel -source. Various bits of information about the Linux kernel and the -device drivers shipped with it are documented in these files. - -You'll want to install this package if you need a reference to the -options that can be passed to Linux kernel modules at load time. - - -%package headers -Summary: Header files for the Linux kernel for use by glibc -Group: Development/System -Obsoletes: glibc-kernheaders -Provides: glibc-kernheaders = 3.0-46 -%description headers -Kernel-headers includes the C header files that specify the interface -between the Linux kernel and userspace libraries and programs. The -header files define structures and constants that are needed for -building most standard programs and are also needed for rebuilding the -glibc package. - - -%package debug -Summary: The Linux kernel compiled with extra debugging enabled. -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}debug -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -AutoReq: no -AutoProv: yes +%define variant_summary The Linux kernel compiled with extra debugging enabled +%kernel_variant_package debug %description debug The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions @@ -818,107 +768,21 @@ This variant of the kernel has numerous It should only be installed when trying to gather additional information on kernel bugs, as some of these options impact performance noticably. -%package debug-debuginfo -Summary: Debug information for package %{name}-debug -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-debug-debuginfo-%{_target_cpu} = %{KVERREL} -%description debug-debuginfo -This package provides debug information for package %{name}-debug - -%package debug-devel -Summary: Development package for building kernel modules to match the kernel. -Group: System Environment/Kernel -AutoReqProv: no -Requires(pre): /usr/bin/find -Provides: kernel-debug-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}debug -Provides: kernel-devel = %{rpmversion}-%{release}debug -%description debug-devel -This package provides kernel headers and makefiles sufficient to build modules -against the kernel package. - -%package xen -Summary: The Linux kernel compiled for Xen VM operations -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}xen -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -Conflicts: %{xen_conflicts} -# 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 -AutoReq: no -AutoProv: yes +%define variant_summary The Linux kernel compiled for Xen VM operations +%kernel_variant_package -n Xen xen %description xen This package includes a version of the Linux kernel which -runs in Xen VM. It works for both priviledged and unpriviledged guests. - -%package xen-debuginfo -Summary: Debug information for package %{name}-xen -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-xen-debuginfo-%{_target_cpu} = %{KVERREL} -%description xen-debuginfo -This package provides debug information for package %{name}-xen -This is required to use SystemTap with %{name}-xen-%{KVERREL}. +runs in a Xen VM. It works for both privileged and unprivileged guests. -%package xen-devel -Summary: Development package for building kernel modules to match the kernel. -Group: System Environment/Kernel -AutoReqProv: no -Provides: kernel-xen-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}xen -Provides: kernel-devel = %{rpmversion}-%{release}xen -Requires(pre): /usr/bin/find -%description xen-devel -This package provides kernel headers and makefiles sufficient to build modules -against the kernel package. -%package kdump -Summary: A minimal Linux kernel compiled for kernel crash dumps. -Group: System Environment/Kernel -Provides: kernel = %{version} -Provides: kernel-drm = 4.3.0 -Provides: kernel-drm-nouveau = 6 -Provides: kernel-%{_target_cpu} = %{rpmversion}-%{release}kdump -Requires(pre): %{kernel_prereq} -Conflicts: %{kernel_dot_org_conflicts} -Conflicts: %{package_conflicts} -# 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 -AutoReq: no -AutoProv: yes +%define variant_summary A minimal Linux kernel compiled for crash dumps +%kernel_variant_package kdump %description kdump This package includes a kdump version of the Linux kernel. It is required only on machines which will use the kexec-based kernel crash dump mechanism. -%package kdump-debuginfo -Summary: Debug information for package %{name}-kdump -Group: Development/Debug -Requires: %{name}-debuginfo-common-%{_target_cpu} = %{KVERREL} -Provides: %{name}-kdump-debuginfo-%{_target_cpu} = %{KVERREL} -%description kdump-debuginfo -This package provides debug information for package %{name}-kdump -This is required to use SystemTap with %{name}-kdump-%{KVERREL}. - -%package kdump-devel -Summary: Development package for building kernel modules to match the kdump kernel. -Group: System Environment/Kernel -Provides: kernel-kdump-devel-%{_target_cpu} = %{rpmversion}-%{release} -Provides: kernel-devel-%{_target_cpu} = %{rpmversion}-%{release}kdump -Provides: kernel-devel = %{rpmversion}-%{release}kdump -AutoReqProv: no -Requires(pre): /usr/bin/find -%description kdump-devel -This package provides kernel headers and makefiles sufficient to build modules -against the kdump kernel package. - %prep # do a few sanity-checks for --with *only builds @@ -1665,494 +1529,91 @@ rm -rf $RPM_BUILD_ROOT ### scripts ### -%post -if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ]; then - if [ -f /etc/sysconfig/kernel ]; then - /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $? - fi -fi -/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install %{KVERREL} || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL} || exit $? -#fi - -%post devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - -%post smp -/sbin/new-kernel-pkg --package kernel-smp --mkinitrd --depmod --install %{KVERREL}smp || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL}smp || exit $? -#fi - -%post smp-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-smp-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - -%post PAE -if [ -f /etc/sysconfig/kernel ]; then - /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel-PAE/' /etc/sysconfig/kernel -fi -/sbin/new-kernel-pkg --package kernel-PAE --mkinitrd --depmod --install %{KVERREL}PAE || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL}PAE || exit $? -#fi - -%post PAE-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-PAE-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - - -%post debug -/sbin/new-kernel-pkg --package kernel-debug --mkinitrd --depmod --install %{KVERREL}debug || exit $? -if [ -x /sbin/weak-modules ] -then - /sbin/weak-modules --add-kernel %{KVERREL}debug || exit $? -fi +# +# This macro defines a %%post script for a kernel*-devel package. +# %%kernel_devel_post +# +%define kernel_devel_post() \ +%{expand:%%post %{?1:%{1}-}devel}\ +if [ -f /etc/sysconfig/kernel ]\ +then\ + . /etc/sysconfig/kernel || exit $?\ +fi\ +if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ]\ +then\ + (cd /usr/src/kernels/%{KVERREL}-%{?1:%{1}-}%{_target_cpu} &&\ + /usr/bin/find . -type f | while read f; do\ + hardlink -c /usr/src/kernels/*.fc*-*/$f $f\ + done)\ +fi\ +%{nil} + +# +# This macro defines a %%post script for a kernel package and its devel package. +# %%kernel_variant_post [-v ] [-s -r ] +# More text can follow to go at the end of this variant's %%post. +# +%define kernel_variant_post(s:r:v:) \ +%{expand:%%kernel_devel_post %{?-v*}}\ +%{expand:%%post %{?-v*}}\ +%{-s:\ +if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\ + [ -f /etc/sysconfig/kernel ]; then\ + /bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/' /etc/sysconfig/kernel || exit $?\ +fi}\ +/sbin/new-kernel-pkg --package kernel%{?1:-%{1}} --mkinitrd --depmod --install %{?2} %{KVERREL}%{?1} || exit $?\ +if [ -x /sbin/weak-modules ]\ +then\ + /sbin/weak-modules --add-kernel %{KVERREL}%{?1} || exit $?\ +fi\ +%{nil} + +# +# This macro defines a %%preun script for a kernel package. +# %%kernel_variant_preun +# +%define kernel_variant_preun() \ +%{expand:%%preun %{?1}}\ +/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\ +if [ -x /sbin/weak-modules ]\ +then\ + /sbin/weak-modules --remove-kernel %{KVERREL}%{?1} || exit $?\ +fi\ +%{nil} + +%kernel_variant_preun +%kernel_variant_post -s kernel-smp -r kernel + +%kernel_variant_preun smp +%kernel_variant_post -v smp + +%kernel_variant_preun PAE +%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE -%post debug-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-debug-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi +%kernel_variant_preun debug +%kernel_variant_post -v debug -%post PAE-debug -if [ -f /etc/sysconfig/kernel ]; then - /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel-PAE/' /etc/sysconfig/kernel -fi -/sbin/new-kernel-pkg --package kernel-PAE --mkinitrd --depmod --install %{KVERREL}PAE-debug || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL}PAE || exit $? -#fi +%kernel_variant_post -v PAE-debug -s kernel-smp -r kernel-PAE-debug +%kernel_variant_preun PAE-debug -%post PAE-debug-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-PAE-debug-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - -%post xen -if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ]; then - if [ -f /etc/sysconfig/kernel ]; then - /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-xen[0U]/DEFAULTKERNEL=kernel-xen/' /etc/sysconfig/kernel || exit $? - fi -fi -if [ -e /proc/xen/xsd_kva -o ! -d /proc/xen ]; then - /sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install --multiboot=/%{image_install_path}/xen.gz-%{KVERREL} %{KVERREL}xen || exit $? -else - /sbin/new-kernel-pkg --package kernel-xen --mkinitrd --depmod --install %{KVERREL}xen || exit $? -fi +%kernel_variant_preun xen +%kernel_variant_post xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen -a ! -e /proc/xen/xsd_kva ] || echo --multiboot=/%{image_install_path}/xen.gz-%{KVERREL}` if [ -x /sbin/ldconfig ] then /sbin/ldconfig -X || exit $? fi -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL}xen || exit $? -#fi - -%post xen-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-xen-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - -%post kdump -/sbin/new-kernel-pkg --package kernel-kdump --mkinitrd --depmod --install %{KVERREL}kdump || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --add-kernel %{KVERREL}kdump || exit $? -#fi - -%post kdump-devel -if [ -f /etc/sysconfig/kernel ] -then - . /etc/sysconfig/kernel || exit $? -fi -if [ "$HARDLINK" != "no" -a -x /usr/sbin/hardlink ] ; then - pushd /usr/src/kernels/%{KVERREL}-kdump-%{_target_cpu} > /dev/null - /usr/bin/find . -type f | while read f; do hardlink -c /usr/src/kernels/*FC*/$f $f ; done - popd > /dev/null -fi - - -%preun -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL} || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL} || exit $? -#fi - -%preun smp -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}smp || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL}smp || exit $? -#fi - -%preun PAE -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}PAE || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL}PAE || exit $? -#fi - -%preun kdump -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}kdump || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL}kdump || exit $? -#fi - -%preun debug -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}debug || exit $? -if [ -x /sbin/weak-modules ] -then - /sbin/weak-modules --remove-kernel %{KVERREL}debug || exit $? -fi - -%preun PAE-debug -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}PAE-debug || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL}PAE || exit $? -#fi - -%preun xen -/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}xen || exit $? -#if [ -x /sbin/weak-modules ] -#then -# /sbin/weak-modules --remove-kernel %{KVERREL}xen || exit $? -#fi ### ### file lists ### -# 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}} - -%if %{with_up} -%if %{with_debuginfo} -%ifnarch noarch -%files debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL} -%{debuginfodir}/usr/src/kernels/%{KVERREL}-%{_target_cpu} -%endif -%endif - -%files -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL} -/boot/System.map-%{KVERREL} -#/boot/symvers-%{KVERREL}.gz -/boot/config-%{KVERREL} -%dir /lib/modules/%{KVERREL} -/lib/modules/%{KVERREL}/kernel -/lib/modules/%{KVERREL}/build -/lib/modules/%{KVERREL}/source -/lib/modules/%{KVERREL}/extra -/lib/modules/%{KVERREL}/updates -/lib/modules/%{KVERREL}/weak-updates -/lib/modules/%{KVERREL}/modules.scsi -/lib/modules/%{KVERREL}/modules.libata -/lib/modules/%{KVERREL}/modules.networking -%ghost /boot/initrd-%{KVERREL}.img - -%files devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-%{_target_cpu} -%endif - - %if %{with_headers} %files headers %defattr(-,root,root) /usr/include/* %endif - -%if %{with_debug} -%if %{with_debuginfo} -%ifnarch noarch -%files debug-debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}debug.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}debug -%{debuginfodir}/usr/src/kernels/%{KVERREL}-debug-%{_target_cpu} -%endif - -%files debug -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL}debug -/boot/System.map-%{KVERREL}debug -#/boot/symvers-%{KVERREL}debug.gz -/boot/config-%{KVERREL}debug -%dir /lib/modules/%{KVERREL}debug -/lib/modules/%{KVERREL}debug/kernel -/lib/modules/%{KVERREL}debug/build -/lib/modules/%{KVERREL}debug/source -/lib/modules/%{KVERREL}debug/extra -/lib/modules/%{KVERREL}debug/updates -/lib/modules/%{KVERREL}debug/weak-updates -/lib/modules/%{KVERREL}debug/modules.scsi -/lib/modules/%{KVERREL}debug/modules.libata -/lib/modules/%{KVERREL}debug/modules.networking -%ghost /boot/initrd-%{KVERREL}debug.img - -%files debug-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-debug-%{_target_cpu} -/usr/src/kernels/%{KVERREL}debug-%{_target_cpu} -%endif -%endif - - - -%if %{with_pae} -%if %{with_debuginfo} -%ifnarch noarch -%files PAE-debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}PAE.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}PAE -%{debuginfodir}/usr/src/kernels/%{KVERREL}-PAE-%{_target_cpu} -%endif -%endif - -%files PAE -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL}PAE -/boot/System.map-%{KVERREL}PAE -#/boot/symvers-%{KVERREL}PAE.gz -/boot/config-%{KVERREL}PAE -%dir /lib/modules/%{KVERREL}PAE -/lib/modules/%{KVERREL}PAE/kernel -/lib/modules/%{KVERREL}PAE/build -/lib/modules/%{KVERREL}PAE/source -/lib/modules/%{KVERREL}PAE/extra -/lib/modules/%{KVERREL}PAE/updates -/lib/modules/%{KVERREL}PAE/weak-updates -/lib/modules/%{KVERREL}PAE/modules.scsi -/lib/modules/%{KVERREL}PAE/modules.libata -/lib/modules/%{KVERREL}PAE/modules.networking -%ghost /boot/initrd-%{KVERREL}PAE.img - -%files PAE-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-PAE-%{_target_cpu} -/usr/src/kernels/%{KVERREL}PAE-%{_target_cpu} - -%if %{with_debug} -%if %{with_debuginfo} -%ifnarch noarch -%files PAE-debug-debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}PAE-debug.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}PAE-debug -%{debuginfodir}/usr/src/kernels/%{KVERREL}-PAE-debug-%{_target_cpu} -%endif - -%files PAE-debug -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL}PAE-debug -/boot/System.map-%{KVERREL}PAE-debug -#/boot/symvers-%{KVERREL}PAE-debug.gz -/boot/config-%{KVERREL}PAE-debug -%dir /lib/modules/%{KVERREL}PAE-debug -/lib/modules/%{KVERREL}PAE-debug/kernel -/lib/modules/%{KVERREL}PAE-debug/build -/lib/modules/%{KVERREL}PAE-debug/source -/lib/modules/%{KVERREL}PAE-debug/extra -/lib/modules/%{KVERREL}PAE-debug/updates -/lib/modules/%{KVERREL}PAE-debug/weak-updates -/lib/modules/%{KVERREL}PAE-debug/modules.scsi -/lib/modules/%{KVERREL}PAE-debug/modules.libata -/lib/modules/%{KVERREL}PAE-debug/modules.networking -%ghost /boot/initrd-%{KVERREL}PAE-debug.img - -%files PAE-debug-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-PAE-debug-%{_target_cpu} -/usr/src/kernels/%{KVERREL}PAE-debug-%{_target_cpu} -%endif -%endif -# PAE -%endif - - -%if %{with_smp} -%if %{with_debuginfo} -%ifnarch noarch -%files smp-debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}smp.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}smp -%{debuginfodir}/usr/src/kernels/%{KVERREL}-smp-%{_target_cpu} -%endif -%endif - -%files smp -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL}smp -/boot/System.map-%{KVERREL}smp -#/boot/symvers-%{KVERREL}smp.gz -/boot/config-%{KVERREL}smp -%dir /lib/modules/%{KVERREL}smp -/lib/modules/%{KVERREL}smp/kernel -/lib/modules/%{KVERREL}smp/build -/lib/modules/%{KVERREL}smp/source -/lib/modules/%{KVERREL}smp/extra -/lib/modules/%{KVERREL}smp/updates -/lib/modules/%{KVERREL}smp/weak-updates -/lib/modules/%{KVERREL}smp/modules.scsi -/lib/modules/%{KVERREL}smp/modules.libata -/lib/modules/%{KVERREL}smp/modules.networking -%ghost /boot/initrd-%{KVERREL}smp.img - -%files smp-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-smp-%{_target_cpu} -/usr/src/kernels/%{KVERREL}smp-%{_target_cpu} -%endif - - -%if %{includexen} -%if %{with_xen} -%if %{with_debuginfo} -%ifnarch noarch -%files xen-debuginfo -%defattr(-,root,root) -%if "%{elf_image_install_path}" != "" -%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}xen.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}xen -%{debuginfodir}/usr/src/kernels/%{KVERREL}-xen-%{_target_cpu} -%{debuginfodir}/boot/xen*-%{KVERREL}.debug -%endif -%endif - -%files xen -%defattr(-,root,root) -/%{image_install_path}/vmlinuz-%{KVERREL}xen -/boot/System.map-%{KVERREL}xen -#/boot/symvers-%{KVERREL}xen.gz -/boot/config-%{KVERREL}xen -/%{image_install_path}/xen.gz-%{KVERREL} -/boot/xen-syms-%{KVERREL} -%dir /lib/modules/%{KVERREL}xen -/lib/modules/%{KVERREL}xen/kernel -%verify(not mtime) /lib/modules/%{KVERREL}xen/build -/lib/modules/%{KVERREL}xen/source -/etc/ld.so.conf.d/kernelcap-%{KVERREL}.conf -/lib/modules/%{KVERREL}xen/extra -/lib/modules/%{KVERREL}xen/updates -/lib/modules/%{KVERREL}xen/weak-updates -/lib/modules/%{KVERREL}xen/modules.scsi -/lib/modules/%{KVERREL}xen/modules.libata -/lib/modules/%{KVERREL}xen/modules.networking -%ghost /boot/initrd-%{KVERREL}xen.img - -%files xen-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-xen-%{_target_cpu} -/usr/src/kernels/%{KVERREL}xen-%{_target_cpu} -%endif -%endif - -%if %{with_kdump} -%if %{with_debuginfo} -%ifnarch noarch -%files kdump-debuginfo -%defattr(-,root,root) -%if "%{image_install_path}" != "" -%{debuginfodir}/%{image_install_path}/*-%{KVERREL}kdump.debug -%endif -%{debuginfodir}/lib/modules/%{KVERREL}kdump -%{debuginfodir}/usr/src/kernels/%{KVERREL}-kdump-%{_target_cpu} -%endif -%endif - -%files kdump -%defattr(-,root,root) -/%{image_install_path}/vmlinux-%{KVERREL}kdump -/boot/System.map-%{KVERREL}kdump -#/boot/symvers-%{KVERREL}kdump.gz -/boot/config-%{KVERREL}kdump -%dir /lib/modules/%{KVERREL}kdump -/lib/modules/%{KVERREL}kdump/kernel -/lib/modules/%{KVERREL}kdump/build -/lib/modules/%{KVERREL}kdump/source -/lib/modules/%{KVERREL}kdump/extra -/lib/modules/%{KVERREL}kdump/updates -/lib/modules/%{KVERREL}kdump/weak-updates -/lib/modules/%{KVERREL}kdump/modules.scsi -/lib/modules/%{KVERREL}kdump/modules.libata -/lib/modules/%{KVERREL}kdump/modules.networking -%ghost /boot/initrd-%{KVERREL}kdump.img - -%files kdump-devel -%defattr(-,root,root) -%verify(not mtime) /usr/src/kernels/%{KVERREL}-kdump-%{_target_cpu} -/usr/src/kernels/%{KVERREL}kdump-%{_target_cpu} -%endif - # only some architecture builds need kernel-doc - %if %{with_doc} %files doc %defattr(-,root,root) @@ -2161,6 +1622,64 @@ fi %dir %{_datadir}/doc/kernel-doc-%{kversion} %endif +# 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}} + +# +# This macro defines the %files sections for a kernel package +# and its devel and debuginfo packages. +# %%kernel_variant_files [-a ] [-e ] +# +%define kernel_variant_files(a:e:) \ +%if %{1}\ +%{expand:%%files %{?2}}\ +%defattr(-,root,root)\ +/%{image_install_path}/vmlinuz-%{KVERREL}%{?2}\ +/boot/System.map-%{KVERREL}%{?2}\ +#/boot/symvers-%{KVERREL}%{?2}.gz\ +/boot/config-%{KVERREL}%{?2}\ +%{?-a:%{-a*}}\ +%dir /lib/modules/%{KVERREL}%{?2}\ +/lib/modules/%{KVERREL}%{?2}/kernel\ +/lib/modules/%{KVERREL}%{?2}/build\ +/lib/modules/%{KVERREL}%{?2}/source\ +/lib/modules/%{KVERREL}%{?2}/extra\ +/lib/modules/%{KVERREL}%{?2}/updates\ +/lib/modules/%{KVERREL}%{?2}/weak-updates\ +/lib/modules/%{KVERREL}%{?2}/modules.scsi\ +/lib/modules/%{KVERREL}%{?2}/modules.libata\ +/lib/modules/%{KVERREL}%{?2}/modules.networking\ +%ghost /boot/initrd-%{KVERREL}%{?2}.img\ +%{?-e:%{-e*}}\ +%{expand:%%files %{?2:%{2}-}devel}\ +%defattr(-,root,root)\ +%verify(not mtime) /usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ +/usr/src/kernels/%{KVERREL}%{?2}-%{_target_cpu}\ +%if %{with_debuginfo}\ +%ifnarch noarch\ +%{expand:%%files %{?2:%{2}-}debuginfo}\ +%defattr(-,root,root)\ +%if "%{elf_image_install_path}" != ""\ +%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\ +%endif\ +%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\ +%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ +%{?-a:%{debuginfodir}%{-a*}.debug}\ +%endif\ +%endif\ +%endif\ +%{nil} + +%kernel_variant_files %{with_up} +%kernel_variant_files %{with_smp} smp +%kernel_variant_files %{with_debug} debug +%kernel_variant_files %{with_pae} PAE +%kernel_variant_files %{with_pae_debug} PAE-debug +%kernel_variant_files %{with_kdump} kdump +%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL} -e /etc/ld.so.conf.d/kernelcap-%{KVERREL}.conf %{with_xen} xen + + %changelog * Tue Jul 31 2007 John W. Linville - Update git-wireless-dev.patch (iwlwifi, rt2x00, & zd1211rw updates) From davej at redhat.com Wed Aug 1 18:15:15 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Aug 2007 14:15:15 -0400 Subject: macrofied kernel.spec In-Reply-To: <20070801021105.19E144D04B9@magilla.localdomain> References: <20070801021105.19E144D04B9@magilla.localdomain> Message-ID: <20070801181515.GA28082@redhat.com> On Tue, Jul 31, 2007 at 07:11:05PM -0700, Roland McGrath wrote: > (I say this, but then, I wrote the glibc makefiles as a child, so > my judgment is clearly suspect, and my breeding a lost cause.) What is this, a counselling list now? :-) > I think this is a nice cleanup on its own. The reason I actually > did it is that the debuginfo package details will have to change > soon when a new find-debuginfo.sh comes in rpm, which is cleaned up > generally and does new magic for the build-id stuff. I really > don't want to have to start dicking with that before it's > consolidated into only one place I have to touch. > > I've verified that this is a no-op vs the 0.61 build. i.e., it > generates rpms with the same files and same rpm magic, modulo a few > typo fixes and cosmetic cleanups/consolidation of rpm script fragments. > > In the absence of frothing vitriol, I will commit this after > f8-test1 has sailed. My initial reaction was one of shock, but this could just be reaction to the sheer size of the diff. I'll take a look at the post-application specfile later. One thing I did notice though which seemed non-obvious to me.. > +# First the auxiliary packages of the main kernel package. > +%kernel_devel_package > +%kernel_debuginfo_package > + > + > +# Now, each variant package. > + > +%define variant_summary The Linux kernel compiled for SMP machines > +%kernel_variant_package -n SMP smp Do -debuginfo packages for variants get produced automatically? I'm assuming yes based on this part of the macro.. > +%if %{with_debuginfo}\ > +%ifnarch noarch\ > +%{expand:%%files %{?2:%{2}-}debuginfo}\ > +%defattr(-,root,root)\ > +%if "%{elf_image_install_path}" != ""\ > +%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\ > +%endif\ > +%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\ > +%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ > +%{?-a:%{debuginfodir}%{-a*}.debug}\ > +%endif\ > +%endif\ > +%endif\ but for some reason, it doesn't sit right in my head. I've no real fundamental objection to this, but don't leave the country or have any accidents for a while after it goes in :-) Just as when Jarod did the versioning overhaul, if something goes awry, you'd probably be able to figure out the problem quicker than those getting up to speed on what you've done so far. Dave -- http://www.codemonkey.org.uk From ehabkost at redhat.com Wed Aug 1 19:06:14 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Wed, 1 Aug 2007 16:06:14 -0300 Subject: macrofied kernel.spec In-Reply-To: <20070801181515.GA28082@redhat.com> References: <20070801021105.19E144D04B9@magilla.localdomain> <20070801181515.GA28082@redhat.com> Message-ID: <20070801190613.GM10411@blackpad.ctb.virtua.com.br> On Wed, Aug 01, 2007 at 02:15:15PM -0400, Dave Jones wrote: > > Do -debuginfo packages for variants get produced automatically? > > I'm assuming yes based on this part of the macro.. > > > +%if %{with_debuginfo}\ > > +%ifnarch noarch\ > > +%{expand:%%files %{?2:%{2}-}debuginfo}\ > > +%defattr(-,root,root)\ > > +%if "%{elf_image_install_path}" != ""\ > > +%{debuginfodir}/%{elf_image_install_path}/*-%{KVERREL}%{?2}.debug\ > > +%endif\ > > +%{debuginfodir}/lib/modules/%{KVERREL}%{?2}\ > > +%{debuginfodir}/usr/src/kernels/%{KVERREL}%{?2:-%{2}}-%{_target_cpu}\ > > +%{?-a:%{debuginfodir}%{-a*}.debug}\ > > +%endif\ > > +%endif\ > > +%endif\ > > but for some reason, it doesn't sit right in my head. > > I've no real fundamental objection to this, but don't leave the country > or have any accidents for a while after it goes in :-) > Just as when Jarod did the versioning overhaul, if something goes awry, > you'd probably be able to figure out the problem quicker than those > getting up to speed on what you've done so far. Having been through the (painful) process of transforming the 2.6.20 FC-6 kernel spec into a kernel-xen spec recently, I liked the change to have less duplicated information through the spec file. The macro expansion syntax of RPM is ugly, but I would prefer that than having a big spec file with lots of duplicated info. If Roland hide, leave the country, or something like this, I offer myself to help on this if something goes wrong. :) -- Eduardo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Wed Aug 1 19:09:04 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 01 Aug 2007 15:09:04 -0400 Subject: macrofied kernel.spec In-Reply-To: <20070801181515.GA28082@redhat.com> References: <20070801021105.19E144D04B9@magilla.localdomain> <20070801181515.GA28082@redhat.com> Message-ID: <46B0DA50.5010709@redhat.com> Dave Jones wrote: > On Tue, Jul 31, 2007 at 07:11:05PM -0700, Roland McGrath wrote: > > I've verified that this is a no-op vs the 0.61 build. i.e., it > > generates rpms with the same files and same rpm magic, modulo a few > > typo fixes and cosmetic cleanups/consolidation of rpm script fragments. > > > > In the absence of frothing vitriol, I will commit this after > > f8-test1 has sailed. > > My initial reaction was one of shock, but this could just be > reaction to the sheer size of the diff. I'll take a look at > the post-application specfile later. I've been intending to do the same. Definitely nice to nuke a bunch of the duplication, but at least in patch form, its not the easiest thing to read and fully comprehend. > I've no real fundamental objection to this, but don't leave the country > or have any accidents for a while after it goes in :-) Indeed, quite some deep-dark-big-bad-voodoo-daddy macro stuff in there to wrap one's head around before trying to make any changes. > Just as when Jarod did the versioning overhaul, if something goes awry, > you'd probably be able to figure out the problem quicker than those > getting up to speed on what you've done so far. Yeah, I thought some of the stuff I did was a bit crazy looking and invasive... This one definitely takes the cake! Okay, spent a while looking at a patched spec file. I think I mostly grok everything, though some of the magic I'm not sure I've ever seen before. I might even feel comfortable trying to fix things iff Roland does leave the country or have an accident... ;) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Wed Aug 1 19:22:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Aug 2007 15:22:16 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070727212441.GA6430@nostromo.devel.redhat.com> References: <20070727021327.GA7175@nostromo.devel.redhat.com> <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> <20070727180329.GB7999@nostromo.devel.redhat.com> <1185559948.15991.49.camel@localhost.localdomain> <20070727182911.GA5691@nostromo.devel.redhat.com> <20070727212441.GA6430@nostromo.devel.redhat.com> Message-ID: <20070801192216.GB26862@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Here you go; sorts them into two piles (networking and block), and expands > the symbol list to catch some of the missing modules such as ahci and > some of the wireless drivers. ... committed. Bill From roland at redhat.com Wed Aug 1 19:26:07 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 1 Aug 2007 12:26:07 -0700 (PDT) Subject: macrofied kernel.spec In-Reply-To: Dave Jones's message of Wednesday, 1 August 2007 14:15:15 -0400 <20070801181515.GA28082@redhat.com> Message-ID: <20070801192607.D92164D04B9@magilla.localdomain> > Do -debuginfo packages for variants get produced automatically? Yes. The %kernel_variant_package macro uses %kernel_debuginfo_package (and %kernel_devel_package). The main package (kernel) uses those two macros, but not %kernel_variant_package. I didn't define a separate %kernel_debuginfo_files for %kernel_variant_files to use because for %kernel_variant_files the main package is just like the others. I could change it to break them out just to make it clearer. Thanks, Roland From roland at redhat.com Wed Aug 1 19:28:00 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 1 Aug 2007 12:28:00 -0700 (PDT) Subject: macrofied kernel.spec In-Reply-To: Jarod Wilson's message of Wednesday, 1 August 2007 15:09:04 -0400 <46B0DA50.5010709@redhat.com> Message-ID: <20070801192800.139704D04B9@magilla.localdomain> > I've been intending to do the same. Definitely nice to nuke a bunch of > the duplication, but at least in patch form, its not the easiest thing > to read and fully comprehend. Yes, don't try to read the patch. (It also gratuitously reorders a couple things, because that makes the final kernel.spec easier to read.) > Okay, spent a while looking at a patched spec file. I think I mostly > grok everything, though some of the magic I'm not sure I've ever seen > before. I might even feel comfortable trying to fix things iff Roland > does leave the country or have an accident... ;) If there is anything that you think should have more comments, let me know. I didn't bother with any comments explaining the % syntax being used. But probably there should be some. Like most things in rpm, 80% of the relevant details are not documented anywhere. From drago01 at gmail.com Thu Aug 2 18:20:26 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 2 Aug 2007 20:20:26 +0200 Subject: kqemu inclusion in kernel In-Reply-To: <20070616142145.GJ23417@redhat.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> Message-ID: On 6/16/07, Dave Jones wrote: > > On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > > > I've started playing around with virtualization at work and the first > thing > > I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It > was > > GPL'd in February and although I realise Axel is packaging kmdl/kmods it > > would be good to know if this is being queued up for mainline. > > not afaik.. I've not heard of anyone working on it since its initial > opensource'ing, which seemed to be a reactionary thing in response to > kvm's gaining popularity. > > > If not then can it be backported for Fedora kernels. > > It was fairly big (but not really invasive fwir), but it's still a delta > that we'd perpetually have to carry vs upstream. Each patch adds a > burden towards rebasing, and with no clear path for this to get > upstream, it's questionable how long we'd have to carry it, so I'm > not too enthusiastic to be honest. well but kqemu seems not to break that often I just recompile it after each kernel release and it just works. the code might be big but it does not depend on (fast) changing interfaces. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cebbert at redhat.com Thu Aug 2 18:25:03 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 02 Aug 2007 14:25:03 -0400 Subject: kqemu inclusion in kernel In-Reply-To: References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> Message-ID: <46B2217F.6000206@redhat.com> On 08/02/2007 02:20 PM, dragoran wrote: > > well but kqemu seems not to break that often I just recompile it after each > kernel release and it just works. > the code might be big but it does not depend on (fast) changing interfaces. > Maybe I missed the earlier discussions, but just what does kqemu give you that KVM doesn't? From jwilson at redhat.com Thu Aug 2 18:27:01 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 02 Aug 2007 14:27:01 -0400 Subject: kqemu inclusion in kernel In-Reply-To: <46B2217F.6000206@redhat.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <46B2217F.6000206@redhat.com> Message-ID: <46B221F5.4060001@redhat.com> Chuck Ebbert wrote: > On 08/02/2007 02:20 PM, dragoran wrote: >> well but kqemu seems not to break that often I just recompile it after each >> kernel release and it just works. >> the code might be big but it does not depend on (fast) changing interfaces. >> > > Maybe I missed the earlier discussions, but just what does kqemu give > you that KVM doesn't? Acceleration of non-hardware-virt guests. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drago01 at gmail.com Thu Aug 2 18:38:27 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 2 Aug 2007 20:38:27 +0200 Subject: kqemu inclusion in kernel In-Reply-To: <46B2217F.6000206@redhat.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <46B2217F.6000206@redhat.com> Message-ID: On 8/2/07, Chuck Ebbert wrote: > > On 08/02/2007 02:20 PM, dragoran wrote: > > > > well but kqemu seems not to break that often I just recompile it after > each > > kernel release and it just works. > > the code might be big but it does not depend on (fast) changing > interfaces. > > > > Maybe I missed the earlier discussions, but just what does kqemu give > you that KVM doesn't? when your cpu does not support HVM kvm is useless ... kqemu does not use hvm for acceleration so it works on this hw too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Aug 2 20:31:33 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Aug 2007 16:31:33 -0400 Subject: kqemu inclusion in kernel In-Reply-To: References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> Message-ID: <20070802203133.GA29643@redhat.com> On Thu, Aug 02, 2007 at 08:20:26PM +0200, dragoran wrote: > On 6/16/07, Dave Jones wrote: > > > > On Sat, Jun 16, 2007 at 03:13:56PM +0100, Chris Brown wrote: > > > > > I've started playing around with virtualization at work and the first > > thing > > > I'd like to query is kqemu's lack of inclusion in the Fedora kernel. It > > was > > > GPL'd in February and although I realise Axel is packaging kmdl/kmods it > > > would be good to know if this is being queued up for mainline. > > > > not afaik.. I've not heard of anyone working on it since its initial > > opensource'ing, which seemed to be a reactionary thing in response to > > kvm's gaining popularity. > > > > > If not then can it be backported for Fedora kernels. > > > > It was fairly big (but not really invasive fwir), but it's still a delta > > that we'd perpetually have to carry vs upstream. Each patch adds a > > burden towards rebasing, and with no clear path for this to get > > upstream, it's questionable how long we'd have to carry it, so I'm > > not too enthusiastic to be honest. > > > well but kqemu seems not to break that often I just recompile it after each > kernel release and it just works. > the code might be big but it does not depend on (fast) changing interfaces. I'm really against merging more 'not upstream' things. We make a big deal about how close to upstream we are, and frankly in the last year or so, we've _sucked_ at keeping that statement true. Whilst some stuff is likely to end up in upstream at some point (utrace for eg), other stuff is perpetual baggage that is a pita when it comes to rebasing. Each release, we're getting closer though, as more and more old stuff gets thrown away. For eg, for F7, no-one cared enough about tux to really keep it maintained. Result - gone. Xen became such a hindrance it ended up having to go to its own package. The wireless stuff seems to be a sliding patchset, where the stuff it contains ends up upstream, but at the same time, a new batch of not yet upstream stuff arrives. I'm hoping eventually that too will settle down, but adding a driver here and a driver there is a path that I'd really rather we didn't travel due to the ongoing maintainence headache that it involves. A much better way to get this stuff into Fedora is to find out why it isn't getting upstream, and get involved with whatever cleanup work is necessary to get it there. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Thu Aug 2 20:34:43 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 02 Aug 2007 16:34:43 -0400 Subject: macrofied kernel.spec In-Reply-To: <20070801192800.139704D04B9@magilla.localdomain> References: <20070801192800.139704D04B9@magilla.localdomain> Message-ID: <46B23FE3.7000002@redhat.com> Roland McGrath wrote: >> I've been intending to do the same. Definitely nice to nuke a bunch of >> the duplication, but at least in patch form, its not the easiest thing >> to read and fully comprehend. > > Yes, don't try to read the patch. (It also gratuitously reorders a couple > things, because that makes the final kernel.spec easier to read.) Just realized it looks like you also snuck in a kernel-PAE-debug build variant... ;) Damn, it'd be nice if koji could spread kernel variant builds of the same arch across multiple builders... >> Okay, spent a while looking at a patched spec file. I think I mostly >> grok everything, though some of the magic I'm not sure I've ever seen >> before. I might even feel comfortable trying to fix things iff Roland >> does leave the country or have an accident... ;) > > If there is anything that you think should have more comments, let me know. > I didn't bother with any comments explaining the % syntax being used. > But probably there should be some. I've read through everything a few more times, and I'm even more sure I get everything now. The main hang-up was the flag passing. Similar, I've not seen %1 and %2 used a whole lot, so I think that could be confusing to some people. They all make sense to me, but I've not really seen their use documented anywhere. But I'm not sure the kernel spec is the place to document them... Some of the documentation about what the -s and -r flags represent in the %kernel_variant_post would probably be worth adding though (just says [-s -r ] right now in the comment header, and my best guess is s=string, r=replacement). Maybe also some clarification that %kernel_devel_package and %kernel_debuginfo_package are used for both kernel- and kernel -- the comments make it appear they're for kernel- only. Though "This macro creates a kernel[-]-devel package" is a wee bit confusing too... Maybe I'm just being nit-picky there, those parts are probably fine, since for the most part, people really shouldn't ever have to touch these macro defs anyhow. Only other thing I'm seeing right now, though its probably been this way forever, is that we're a bit inconsistent about whether we use %{name} or just 'kernel' in %package and %description. > Like most things in rpm, 80% of the > relevant details are not documented anywhere. Yeah, no kidding... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From paul at xelerance.com Thu Aug 2 20:35:23 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 2 Aug 2007 16:35:23 -0400 (EDT) Subject: kqemu inclusion in kernel In-Reply-To: <20070802203133.GA29643@redhat.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <20070802203133.GA29643@redhat.com> Message-ID: On Thu, 2 Aug 2007, Dave Jones wrote: > A much better way to get this stuff into Fedora is to find out why > it isn't getting upstream, and get involved with whatever cleanup > work is necessary to get it there. Upstream (of which a lot of people are working at RedHat as well, so telling them to go upstream is kinda moot) often don't even start to listen. There is no politics in the kernel, because kernel people are just not enganging in an discussion at all. Paul From roland at redhat.com Thu Aug 2 20:52:44 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 2 Aug 2007 13:52:44 -0700 (PDT) Subject: macrofied kernel.spec In-Reply-To: Jarod Wilson's message of Thursday, 2 August 2007 16:34:43 -0400 <46B23FE3.7000002@redhat.com> Message-ID: <20070802205244.63A9B4D04B5@magilla.localdomain> > Just realized it looks like you also snuck in a kernel-PAE-debug build > variant... ;) Damn, it'd be nice if koji could spread kernel variant > builds of the same arch across multiple builders... I didn't add it, it was already there. I just made it uniform with the others. Maybe the hand-editted duplication had left it not working? Or not entirely removed when it was intended to be? > Some of the documentation about what the -s and -r flags represent in > the %kernel_variant_post would probably be worth adding though (just > says [-s -r ] right now in the comment header, and my best guess > is s=string, r=replacement). Yeah, it forms a sed s command. > Only other thing I'm seeing right now, though its probably been this way > forever, is that we're a bit inconsistent about whether we use %{name} > or just 'kernel' in %package and %description. That matters when doing the variant-source packages like kernel-vanilla, which I haven't tested lately. For the "install the kernel-foo package" parts of %description, %{name}-foo might be better since it will make the literal instructions match the intended reality for that case. For the provides/requires some are intended to be %{name} and some kernel. i.e., %{name}-debuginfo-common-%{_target_cpu}, but kernel-drm. Thanks, Roland From jwilson at redhat.com Thu Aug 2 21:17:15 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 02 Aug 2007 17:17:15 -0400 Subject: macrofied kernel.spec In-Reply-To: <20070802205244.63A9B4D04B5@magilla.localdomain> References: <20070802205244.63A9B4D04B5@magilla.localdomain> Message-ID: <46B249DB.9010103@redhat.com> >> Just realized it looks like you also snuck in a kernel-PAE-debug build= >> variant... ;) Damn, it'd be nice if koji could spread kernel variant >> builds of the same arch across multiple builders... >=20 > I didn't add it, it was already there. I just made it uniform with the= > others. Maybe the hand-editted duplication had left it not working? O= r > not entirely removed when it was intended to be? Huh. So it is... Hrm. Something is apparently causing it to not get built right now though: http://koji.fedoraproject.org/packages/kernel/2.6.23/0.61.rc1.git9.fc8/i6= 86/ (the lack of it showing up there was what made me think you'd added that, serves me right for not looking at the current spec) I'll poke around and see if I can figure out why it isn't getting built. Not obvious at first glance... >> Some of the documentation about what the -s and -r flags represent in >> the %kernel_variant_post would probably be worth adding though (just >> says [-s -r ] right now in the comment header, and my best gues= s >> is s=3Dstring, r=3Dreplacement). >=20 > Yeah, it forms a sed s command. Yep, got that part, just meant that header explanation could have made it clearer what those two flags were for. >> Only other thing I'm seeing right now, though its probably been this w= ay >> forever, is that we're a bit inconsistent about whether we use %{name}= >> or just 'kernel' in %package and %description. >=20 > That matters when doing the variant-source packages like kernel-vanilla= , > which I haven't tested lately. For the "install the kernel-foo package= " > parts of %description, %{name}-foo might be better since it will make t= he > literal instructions match the intended reality for that case. >=20 > For the provides/requires some are intended to be %{name} and some kern= el. > i.e., %{name}-debuginfo-common-%{_target_cpu}, but kernel-drm. I volunteer to go through and try to make everything consistent once the dust settles a bit. --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ehabkost at redhat.com Thu Aug 2 21:18:13 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Thu, 2 Aug 2007 18:18:13 -0300 Subject: macrofied kernel.spec In-Reply-To: <20070802205244.63A9B4D04B5@magilla.localdomain> References: <46B23FE3.7000002@redhat.com> <20070802205244.63A9B4D04B5@magilla.localdomain> Message-ID: <20070802211813.GU10411@blackpad.ctb.virtua.com.br> On Thu, Aug 02, 2007 at 01:52:44PM -0700, Roland McGrath wrote: > > Only other thing I'm seeing right now, though its probably been this way > > forever, is that we're a bit inconsistent about whether we use %{name} > > or just 'kernel' in %package and %description. > > That matters when doing the variant-source packages like kernel-vanilla, > which I haven't tested lately. For the "install the kernel-foo package" > parts of %description, %{name}-foo might be better since it will make the > literal instructions match the intended reality for that case. > > For the provides/requires some are intended to be %{name} and some kernel. > i.e., %{name}-debuginfo-common-%{_target_cpu}, but kernel-drm. On the kernel-xen package, it gets more complicated: because the source package name is 'kernel-xen-2.6', I need to replace most of %{name} occurrences with 'kernel' (I defined a macro for that, %{pkgbasename}) and use "-n %{pkgbasename}-variant" on %package, %description, %files, and other sections. I don't know if the %{pkgbasename} change would be desirable for the main kernel package, but with the new macros, making the changes to use it instead of %{name} on kernel-xen will be easier. -- Eduardo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Fri Aug 3 00:56:04 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Aug 2007 20:56:04 -0400 Subject: /lib/modules/$(uname -r)/modules.* [was Re: Who decides what drivers go on the install disk?] In-Reply-To: <20070801192216.GB26862@nostromo.devel.redhat.com> References: <1185547144.23029.28.camel@jcmlaptop> <20070727162819.GA6909@nostromo.devel.redhat.com> <1185556294.15991.38.camel@localhost.localdomain> <20070727174318.GB7659@nostromo.devel.redhat.com> <1185558591.15991.44.camel@localhost.localdomain> <20070727180329.GB7999@nostromo.devel.redhat.com> <1185559948.15991.49.camel@localhost.localdomain> <20070727182911.GA5691@nostromo.devel.redhat.com> <20070727212441.GA6430@nostromo.devel.redhat.com> <20070801192216.GB26862@nostromo.devel.redhat.com> Message-ID: <20070803005604.GC21172@redhat.com> On Wed, Aug 01, 2007 at 03:22:16PM -0400, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: > > Here you go; sorts them into two piles (networking and block), and expands > > the symbol list to catch some of the missing modules such as ahci and > > some of the wireless drivers. > > ... committed. Bah, missing %files entries for modules.block Fixed it up. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Fri Aug 3 12:49:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Aug 2007 18:19:55 +0530 Subject: kqemu inclusion in kernel In-Reply-To: References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <20070802203133.GA29643@redhat.com> Message-ID: <46B32473.8080601@fedoraproject.org> Paul Wouters wrote: > On Thu, 2 Aug 2007, Dave Jones wrote: > >> A much better way to get this stuff into Fedora is to find out why >> it isn't getting upstream, and get involved with whatever cleanup >> work is necessary to get it there. > > Upstream (of which a lot of people are working at RedHat as well, so > telling them to go upstream is kinda moot) often don't even start to > listen. There is no politics in the kernel, because kernel people are > just not enganging in an discussion at all. Who even submitted these patches upstream to start engaging in a discussion? Rahul From drago01 at gmail.com Fri Aug 3 13:02:37 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 03 Aug 2007 15:02:37 +0200 Subject: kqemu inclusion in kernel In-Reply-To: <46B32473.8080601@fedoraproject.org> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <20070802203133.GA29643@redhat.com> <46B32473.8080601@fedoraproject.org> Message-ID: <46B3276D.7090209@gmail.com> Rahul Sundaram wrote: > Paul Wouters wrote: >> On Thu, 2 Aug 2007, Dave Jones wrote: >> >>> A much better way to get this stuff into Fedora is to find out why >>> it isn't getting upstream, and get involved with whatever cleanup >>> work is necessary to get it there. >> >> Upstream (of which a lot of people are working at RedHat as well, so >> telling them to go upstream is kinda moot) often don't even start to >> listen. There is no politics in the kernel, because kernel people are >> just not enganging in an discussion at all. > > Who even submitted these patches upstream to start engaging in a > discussion? > in case of kqemu nobody... seems qemu upstream isn't really interessted in doing this. From alan at redhat.com Fri Aug 3 14:34:04 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 3 Aug 2007 10:34:04 -0400 Subject: kqemu inclusion in kernel In-Reply-To: <46B3276D.7090209@gmail.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <20070802203133.GA29643@redhat.com> <46B32473.8080601@fedoraproject.org> <46B3276D.7090209@gmail.com> Message-ID: <20070803143404.GB25124@devserv.devel.redhat.com> On Fri, Aug 03, 2007 at 03:02:37PM +0200, dragoran wrote: > >>listen. There is no politics in the kernel, because kernel people are > >>just not enganging in an discussion at all. > > > >Who even submitted these patches upstream to start engaging in a > >discussion? > > > in case of kqemu nobody... seems qemu upstream isn't really interessted > in doing this. Simple observation: kqemu has not been discussed on the kernel list. This is a public list so not a single person since the start of 2007 and maybe before has raised it. That seems to make it less of a priority to the world than some ancient 8bit ISA controller cards From sundaram at fedoraproject.org Fri Aug 3 14:39:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 03 Aug 2007 20:09:13 +0530 Subject: kqemu inclusion in kernel In-Reply-To: <46B3276D.7090209@gmail.com> References: <364d303b0706160713r1b7d9934l64de7993beed7574@mail.gmail.com> <20070616142145.GJ23417@redhat.com> <20070802203133.GA29643@redhat.com> <46B32473.8080601@fedoraproject.org> <46B3276D.7090209@gmail.com> Message-ID: <46B33E11.4050504@fedoraproject.org> dragoran wrote: > Rahul Sundaram wrote: >> Paul Wouters wrote: >>> On Thu, 2 Aug 2007, Dave Jones wrote: >>> >>>> A much better way to get this stuff into Fedora is to find out why >>>> it isn't getting upstream, and get involved with whatever cleanup >>>> work is necessary to get it there. >>> >>> Upstream (of which a lot of people are working at RedHat as well, so >>> telling them to go upstream is kinda moot) often don't even start to >>> listen. There is no politics in the kernel, because kernel people are >>> just not enganging in an discussion at all. >> >> Who even submitted these patches upstream to start engaging in a >> discussion? >> > in case of kqemu nobody... seems qemu upstream isn't really interessted > in doing this. So all the harping on about whether Red Hat developers are involved upstream or not, kernel politics etc is irrelevant. Red Hat kernel developers wouldn't prefer discussing patches to the kernel here either. If anyone is really interested in getting Kqemu in the Fedora, encourage the Kqemu developer to submit his patches to LKML instead of focusing on getting the Fedora kernel maintainers to patch the kernel. Rahul From jwilson at redhat.com Fri Aug 3 16:49:29 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 03 Aug 2007 12:49:29 -0400 Subject: macrofied kernel.spec In-Reply-To: <46B249DB.9010103@redhat.com> References: <20070802205244.63A9B4D04B5@magilla.localdomain> <46B249DB.9010103@redhat.com> Message-ID: <46B35C99.8050301@redhat.com> Jarod Wilson wrote: >>> Just realized it looks like you also snuck in a kernel-PAE-debug build= > >>> variant... ;) Damn, it'd be nice if koji could spread kernel variant >>> builds of the same arch across multiple builders... >> =20 >> I didn't add it, it was already there. I just made it uniform with the= > >> others. Maybe the hand-editted duplication had left it not working? O= > r >> not entirely removed when it was intended to be? > > Huh. So it is... Hrm. Something is apparently causing it to not get > built right now though: > > http://koji.fedoraproject.org/packages/kernel/2.6.23/0.61.rc1.git9.fc8/i6= > 86/ > > (the lack of it showing up there was what made me think you'd added > that, serves me right for not looking at the current spec) > > I'll poke around and see if I can figure out why it isn't getting built. > Not obvious at first glance... Oh. I'm an idiot. Of course they aren't building for rawhide. *ALL* kernels are debug kernels in rawhide, so we don't have a separate one. They're building just fine for F7. /me goes back in his hole... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From samfw at redhat.com Fri Aug 3 18:01:10 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Fri, 03 Aug 2007 14:01:10 -0400 Subject: F8 release notes Message-ID: <46B36D66.10500@redhat.com> Hi, Time to start compiling new features and major bug fixes for inclusion in the F8 release notes. I'm noting... - the addition of x86_64 tickless by default. - the Build ID - Wakeups - Laptop improvements - The changes to the spec file (new macros, changing name to kernel.spec) - Based on 2.6.22? Other items? I will be going through this list, BZ, the kernel changelog, etc - but any replies to this email are appreciated. Thanks, Sam From drago01 at gmail.com Fri Aug 3 18:03:18 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 3 Aug 2007 20:03:18 +0200 Subject: F8 release notes In-Reply-To: <46B36D66.10500@redhat.com> References: <46B36D66.10500@redhat.com> Message-ID: On 8/3/07, Sam Folk-Williams wrote: > > > - Based on 2.6.22? 2.6.23 Other items? http://fedoraproject.org/wiki/Releases/8/FeatureList#approved -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Fri Aug 3 18:27:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Aug 2007 20:27:23 +0200 Subject: F8 release notes In-Reply-To: <46B36D66.10500@redhat.com> References: <46B36D66.10500@redhat.com> Message-ID: <46B3738B.3020809@leemhuis.info> On 03.08.2007 20:01, Sam Folk-Williams wrote: > - the addition of x86_64 tickless by default. In case you don't know: That's disabled currently afaics from http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel.spec?view=markup;root=pkgs ( "#ApplyPatch linux-2.6-highres-timers.patch") Which brings me to the real reason of my mail: when will it get enabled and updated again? Can I/we help somehow? Cu thl From drago01 at gmail.com Fri Aug 3 18:32:55 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 3 Aug 2007 20:32:55 +0200 Subject: F8 release notes In-Reply-To: <46B3738B.3020809@leemhuis.info> References: <46B36D66.10500@redhat.com> <46B3738B.3020809@leemhuis.info> Message-ID: On 8/3/07, Thorsten Leemhuis wrote: > > > > On 03.08.2007 20:01, Sam Folk-Williams wrote: > > - the addition of x86_64 tickless by default. > > In case you don't know: That's disabled currently afaics from > > http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel.spec?view=markup;root=pkgs > ( "#ApplyPatch linux-2.6-highres-timers.patch") > > Which brings me to the real reason of my mail: when will it get enabled > and updated again? there is no patch against 2.6.23-rc1 yet... -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Fri Aug 3 18:41:24 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 3 Aug 2007 14:41:24 -0400 Subject: F8 release notes In-Reply-To: <46B3738B.3020809@leemhuis.info> References: <46B36D66.10500@redhat.com> <46B3738B.3020809@leemhuis.info> Message-ID: <20070803184124.GC16604@redhat.com> On Fri, Aug 03, 2007 at 08:27:23PM +0200, Thorsten Leemhuis wrote: > > > On 03.08.2007 20:01, Sam Folk-Williams wrote: > > - the addition of x86_64 tickless by default. > > In case you don't know: That's disabled currently afaics from > http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/kernel.spec?view=markup;root=pkgs > ( "#ApplyPatch linux-2.6-highres-timers.patch") > > Which brings me to the real reason of my mail: when will it get enabled > and updated again? Can I/we help somehow? Thomas is currently on vacation I believe, so it's in limbo until next week or so. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Sat Aug 4 08:34:12 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 04 Aug 2007 10:34:12 +0200 Subject: why is CONFIG_RTC not set? Message-ID: <46B43A04.1030906@gmail.com> While debugging some qemu problems I wanted to try change the value in /proc/sys/dev/rtc/max-user-freq like suggested from qemu but there is no rtc dir in /proc/sys/dev/ a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: # CONFIG_RTC is not set [..] why is this disabled? Last time I used it it was there (was a while ago but it worked) Reason fro this? From Axel.Thimm at ATrpms.net Sat Aug 4 11:32:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 4 Aug 2007 13:32:35 +0200 Subject: macrofied kernel.spec In-Reply-To: <46B23FE3.7000002@redhat.com> References: <20070801192800.139704D04B9@magilla.localdomain> <46B23FE3.7000002@redhat.com> Message-ID: <20070804113235.GB5410@puariko.nirvana> On Thu, Aug 02, 2007 at 04:34:43PM -0400, Jarod Wilson wrote: > Damn, it'd be nice if koji could spread kernel variant builds of the > same arch across multiple builders... That's not difficult to do - just have exactly one kernel built in the specfile and pass the flavour on the rpmbuild command line in koji. Same is already happening with the kmdl builds since quite some time: Each one is an independent build entity, just copy the idioms from there. Of course koji needs to support several builds per src.rpm which it already does in a way, and also to pass custom --define arguments to the builds, but that's not difficult to embed in koji and would make koji also the platform of choice for building kmdls (which is not an argument for Fedora-internal consumption, but for wider spread use of koji). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Sat Aug 4 17:55:34 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 4 Aug 2007 13:55:34 -0400 Subject: why is CONFIG_RTC not set? In-Reply-To: <46B43A04.1030906@gmail.com> References: <46B43A04.1030906@gmail.com> Message-ID: <20070804175533.GB3391@redhat.com> On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > While debugging some qemu problems I wanted to try change the value in > > /proc/sys/dev/rtc/max-user-freq > > like suggested from qemu but there is no rtc dir in /proc/sys/dev/ > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > # CONFIG_RTC is not set > [..] > > why is this disabled? Last time I used it it was there (was a while ago > but it worked) > Reason fro this? We're using the CONFIG_RTC_CLASS drivers instead. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Sat Aug 4 18:02:02 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 4 Aug 2007 20:02:02 +0200 Subject: why is CONFIG_RTC not set? In-Reply-To: <20070804175533.GB3391@redhat.com> References: <46B43A04.1030906@gmail.com> <20070804175533.GB3391@redhat.com> Message-ID: On 8/4/07, Dave Jones wrote: > > On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > > While debugging some qemu problems I wanted to try change the value in > > > > /proc/sys/dev/rtc/max-user-freq > > > > like suggested from qemu but there is no rtc dir in /proc/sys/dev/ > > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > > > # CONFIG_RTC is not set > > [..] > > > > why is this disabled? Last time I used it it was there (was a while ago > > but it worked) > > Reason fro this? > > We're using the CONFIG_RTC_CLASS drivers instead. ok, how can I change the max user freq with this drivers? a quick google found nothing usefull... Dave > > -- > http://www.codemonkey.org.uk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Sat Aug 4 18:07:20 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 4 Aug 2007 14:07:20 -0400 Subject: why is CONFIG_RTC not set? In-Reply-To: References: <46B43A04.1030906@gmail.com> <20070804175533.GB3391@redhat.com> Message-ID: <20070804180720.GD3391@redhat.com> On Sat, Aug 04, 2007 at 08:02:02PM +0200, dragoran wrote: > On 8/4/07, Dave Jones wrote: > > > > On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > > > While debugging some qemu problems I wanted to try change the value in > > > > > > /proc/sys/dev/rtc/max-user-freq > > > > > > like suggested from qemu but there is no rtc dir in /proc/sys/dev/ > > > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > > > > > # CONFIG_RTC is not set > > > [..] > > > > > > why is this disabled? Last time I used it it was there (was a while ago > > > but it worked) > > > Reason fro this? > > > > We're using the CONFIG_RTC_CLASS drivers instead. > > > ok, how can I change the max user freq with this drivers? > a quick google found nothing usefull... qemu wants to raise that limit. the old driver had a limit of 64hz unless you used the override. The new driver doesn't seem to have this check. It's arguable that it should, and it too should have a sysctl though. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Sat Aug 4 18:10:51 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 4 Aug 2007 20:10:51 +0200 Subject: why is CONFIG_RTC not set? In-Reply-To: <20070804180720.GD3391@redhat.com> References: <46B43A04.1030906@gmail.com> <20070804175533.GB3391@redhat.com> <20070804180720.GD3391@redhat.com> Message-ID: On 8/4/07, Dave Jones wrote: > > On Sat, Aug 04, 2007 at 08:02:02PM +0200, dragoran wrote: > > On 8/4/07, Dave Jones wrote: > > > > > > On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > > > > While debugging some qemu problems I wanted to try change the value > in > > > > > > > > /proc/sys/dev/rtc/max-user-freq > > > > > > > > like suggested from qemu but there is no rtc dir in /proc/sys/dev/ > > > > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > > > > > > > # CONFIG_RTC is not set > > > > [..] > > > > > > > > why is this disabled? Last time I used it it was there (was a while > ago > > > > but it worked) > > > > Reason fro this? > > > > > > We're using the CONFIG_RTC_CLASS drivers instead. > > > > > > ok, how can I change the max user freq with this drivers? > > a quick google found nothing usefull... > > qemu wants to raise that limit. the old driver had a limit of 64hz > unless you used the override. The new driver doesn't seem to have > this check. It's arguable that it should, and it too should > have a sysctl though. so if I understand correctly this driver has hardcoded limits that can't be changed from userspace (yet) ? Dave > > -- > http://www.codemonkey.org.uk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Sat Aug 4 18:28:18 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 4 Aug 2007 14:28:18 -0400 Subject: why is CONFIG_RTC not set? In-Reply-To: References: <46B43A04.1030906@gmail.com> <20070804175533.GB3391@redhat.com> <20070804180720.GD3391@redhat.com> Message-ID: <20070804182818.GA28054@redhat.com> On Sat, Aug 04, 2007 at 08:10:51PM +0200, dragoran wrote: > On 8/4/07, Dave Jones wrote: > > > > On Sat, Aug 04, 2007 at 08:02:02PM +0200, dragoran wrote: > > > On 8/4/07, Dave Jones wrote: > > > > > > > > On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > > > > > While debugging some qemu problems I wanted to try change the value > > in > > > > > > > > > > /proc/sys/dev/rtc/max-user-freq > > > > > > > > > > like suggested from qemu but there is no rtc dir in /proc/sys/dev/ > > > > > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > > > > > > > > > # CONFIG_RTC is not set > > > > > [..] > > > > > > > > > > why is this disabled? Last time I used it it was there (was a while > > ago > > > > > but it worked) > > > > > Reason fro this? > > > > > > > > We're using the CONFIG_RTC_CLASS drivers instead. > > > > > > > > > ok, how can I change the max user freq with this drivers? > > > a quick google found nothing usefull... > > > > qemu wants to raise that limit. the old driver had a limit of 64hz > > unless you used the override. The new driver doesn't seem to have > > this check. It's arguable that it should, and it too should > > have a sysctl though. > > > so if I understand correctly this driver has hardcoded limits that can't be > changed from userspace (yet) ? No, it has no limits. Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Sat Aug 4 18:30:32 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 4 Aug 2007 20:30:32 +0200 Subject: why is CONFIG_RTC not set? In-Reply-To: <20070804182818.GA28054@redhat.com> References: <46B43A04.1030906@gmail.com> <20070804175533.GB3391@redhat.com> <20070804180720.GD3391@redhat.com> <20070804182818.GA28054@redhat.com> Message-ID: On 8/4/07, Dave Jones wrote: > > On Sat, Aug 04, 2007 at 08:10:51PM +0200, dragoran wrote: > > On 8/4/07, Dave Jones wrote: > > > > > > On Sat, Aug 04, 2007 at 08:02:02PM +0200, dragoran wrote: > > > > On 8/4/07, Dave Jones wrote: > > > > > > > > > > On Sat, Aug 04, 2007 at 10:34:12AM +0200, dragoran wrote: > > > > > > While debugging some qemu problems I wanted to try change the > value > > > in > > > > > > > > > > > > /proc/sys/dev/rtc/max-user-freq > > > > > > > > > > > > like suggested from qemu but there is no rtc dir in > /proc/sys/dev/ > > > > > > a cat /boot/config-`uname -r` | grep CONFIG_RTC shows this: > > > > > > > > > > > > # CONFIG_RTC is not set > > > > > > [..] > > > > > > > > > > > > why is this disabled? Last time I used it it was there (was a > while > > > ago > > > > > > but it worked) > > > > > > Reason fro this? > > > > > > > > > > We're using the CONFIG_RTC_CLASS drivers instead. > > > > > > > > > > > > ok, how can I change the max user freq with this drivers? > > > > a quick google found nothing usefull... > > > > > > qemu wants to raise that limit. the old driver had a limit of 64hz > > > unless you used the override. The new driver doesn't seem to have > > > this check. It's arguable that it should, and it too should > > > have a sysctl though. > > > > > > so if I understand correctly this driver has hardcoded limits that > can't be > > changed from userspace (yet) ? > > No, it has no limits. ok -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Sun Aug 5 02:20:55 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 04 Aug 2007 22:20:55 -0400 Subject: macrofied kernel.spec In-Reply-To: <20070804113235.GB5410@puariko.nirvana> References: <20070801192800.139704D04B9@magilla.localdomain> <46B23FE3.7000002@redhat.com> <20070804113235.GB5410@puariko.nirvana> Message-ID: <46B53407.1050700@redhat.com> Axel Thimm wrote: > On Thu, Aug 02, 2007 at 04:34:43PM -0400, Jarod Wilson wrote: >> Damn, it'd be nice if koji could spread kernel variant builds of the >> same arch across multiple builders... > > That's not difficult to do - just have exactly one kernel built in the > specfile and pass the flavour on the rpmbuild command line in koji. > > Same is already happening with the kmdl builds since quite some time: > Each one is an independent build entity, just copy the idioms from > there. > > Of course koji needs to support several builds per src.rpm which it > already does in a way, and also to pass custom --define arguments to > the builds, but that's not difficult to embed in koji and would make > koji also the platform of choice for building kmdls (which is not an > argument for Fedora-internal consumption, but for wider spread use of > koji). With the desire to spin kernel-vanilla rpms off the same source rpm as the current fedora kernels in a way that they aren't scratch builds, I've talked to release engineering about adding support for passing custom flags through the build system before. Unfortunately, they're currently against adding said support, both because of the technical work that would have to be done, and because of some policy matters. If we let builds pass in random flags, the end result binaries might be different than a simple rpmbuild --rebuild would be, we're less sure what was actually built, people could do crazy things, etc., etc., etc. (paraphrasing rel-eng loosely there). Despite that, I'd certainly still like the functionality added, even if its use were restricted to kernels (just what rel-eng wants, more exceptions for the kernel!). Heck, if we could get same-arch kernel variant builds going across multiple build hosts from a single 'make build' invocation, we could maybe even turn on building of a kernel-vanilla package by default without incurring a massive slowdown in 'make build' to 'all builds finished'... -- Jarod Wilson jwilson at redhat.com From cebbert at redhat.com Wed Aug 8 16:59:53 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 12:59:53 -0400 Subject: MSI and MMCONFIG, again... Message-ID: <46B9F689.6040506@redhat.com> We are still hitting problems with MSI (and probably mmconfig) with kernel 2.6.22: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 Should we just go back to disabling these by default? From prarit at redhat.com Wed Aug 8 17:28:58 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Wed, 08 Aug 2007 13:28:58 -0400 Subject: MSI and MMCONFIG, again... In-Reply-To: <46B9F689.6040506@redhat.com> References: <46B9F689.6040506@redhat.com> Message-ID: <46B9FD5A.7030303@redhat.com> Chuck Ebbert wrote: > We are still hitting problems with MSI (and probably mmconfig) > with kernel 2.6.22: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 > > Should we just go back to disabling these by default? > Chuck -- how long have we had this re-enabled? What about (groan) doing quirks for msi/mmconfig? P. > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > > From cebbert at redhat.com Wed Aug 8 17:41:57 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 13:41:57 -0400 Subject: MSI and MMCONFIG, again... In-Reply-To: <46B9FD5A.7030303@redhat.com> References: <46B9F689.6040506@redhat.com> <46B9FD5A.7030303@redhat.com> Message-ID: <46BA0065.5020703@redhat.com> On 08/08/2007 01:28 PM, Prarit Bhargava wrote: >> We are still hitting problems with MSI (and probably mmconfig) >> with kernel 2.6.22: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 >> >> Should we just go back to disabling these by default? >> > > Chuck -- how long have we had this re-enabled? What about (groan) doing > quirks for msi/mmconfig? > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. And there are quirks in there now, I guess the list just isn't complete (and probably never can be.) From cebbert at redhat.com Wed Aug 8 18:17:37 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 14:17:37 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? Message-ID: <46BA08C1.6050101@redhat.com> The pcspkr driver doesn't load automatically any more with kernel 2.6.22. Should we build it in, or maybe add it to the list of drivers that always get loaded? From notting at redhat.com Wed Aug 8 18:21:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Aug 2007 14:21:46 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <46BA08C1.6050101@redhat.com> References: <46BA08C1.6050101@redhat.com> Message-ID: <20070808182146.GC32146@nostromo.devel.redhat.com> Chuck Ebbert (cebbert at redhat.com) said: > The pcspkr driver doesn't load automatically any more with kernel > 2.6.22. > > Should we build it in, or maybe add it to the list of drivers that > always get loaded? Lists are bad - just build it in. Bill From streeter at redhat.com Wed Aug 8 18:22:12 2007 From: streeter at redhat.com (Guy Streeter) Date: Wed, 08 Aug 2007 13:22:12 -0500 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <46BA08C1.6050101@redhat.com> References: <46BA08C1.6050101@redhat.com> Message-ID: <1186597332.18415.1.camel@mentos.hsv.redhat.com> On Wed, 2007-08-08 at 14:17 -0400, Chuck Ebbert wrote: > The pcspkr driver doesn't load automatically any more with kernel > 2.6.22. > > Should we build it in, or maybe add it to the list of drivers that > always get loaded? Please don't build it in. I disable the module on every machine I use. --Guy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Wed Aug 8 18:43:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 8 Aug 2007 13:43:27 -0500 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <20070808182146.GC32146@nostromo.devel.redhat.com> References: <46BA08C1.6050101@redhat.com> <20070808182146.GC32146@nostromo.devel.redhat.com> Message-ID: <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> On Wed, 8 Aug 2007 14:21:46 -0400 Bill Nottingham wrote: > Chuck Ebbert (cebbert at redhat.com) said: > > The pcspkr driver doesn't load automatically any more with kernel > > 2.6.22. > > > > Should we build it in, or maybe add it to the list of drivers that > > always get loaded? > > Lists are bad - just build it in. No! Evil. Unless there's some way to disable it when it's built in. josh From cebbert at redhat.com Wed Aug 8 18:55:28 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 14:55:28 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> References: <46BA08C1.6050101@redhat.com> <20070808182146.GC32146@nostromo.devel.redhat.com> <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> Message-ID: <46BA11A0.3000402@redhat.com> On 08/08/2007 02:43 PM, Josh Boyer wrote: > On Wed, 8 Aug 2007 14:21:46 -0400 > Bill Nottingham wrote: > >> Chuck Ebbert (cebbert at redhat.com) said: >>> The pcspkr driver doesn't load automatically any more with kernel >>> 2.6.22. >>> >>> Should we build it in, or maybe add it to the list of drivers that >>> always get loaded? >> Lists are bad - just build it in. > > No! Evil. Unless there's some way to disable it when it's built in. Okay 2-1 so far. I think it should be added to /etc/sysconfig/modules From notting at redhat.com Wed Aug 8 18:59:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Aug 2007 14:59:22 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <46BA11A0.3000402@redhat.com> References: <46BA08C1.6050101@redhat.com> <20070808182146.GC32146@nostromo.devel.redhat.com> <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> <46BA11A0.3000402@redhat.com> Message-ID: <20070808185922.GA30644@nostromo.devel.redhat.com> Chuck Ebbert (cebbert at redhat.com) said: > > No! Evil. Unless there's some way to disable it when it's built in. > > Okay 2-1 so far. > > I think it should be added to /etc/sysconfig/modules Has any one actually diagnosed how it got loaded before, and why that stopped working? Bill From cebbert at redhat.com Wed Aug 8 19:05:31 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 15:05:31 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <20070808185922.GA30644@nostromo.devel.redhat.com> References: <46BA08C1.6050101@redhat.com> <20070808182146.GC32146@nostromo.devel.redhat.com> <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> <46BA11A0.3000402@redhat.com> <20070808185922.GA30644@nostromo.devel.redhat.com> Message-ID: <46BA13FB.1070506@redhat.com> On 08/08/2007 02:59 PM, Bill Nottingham wrote: > Chuck Ebbert (cebbert at redhat.com) said: >>> No! Evil. Unless there's some way to disable it when it's built in. >> Okay 2-1 so far. >> >> I think it should be added to /etc/sysconfig/modules > > Has any one actually diagnosed how it got loaded before, and why > that stopped working? I gave up trying to figure that one out. Jeff Garzik says it never did work for him; others have reported it worked on i386 but not on x86_64. From notting at redhat.com Wed Aug 8 19:14:15 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 8 Aug 2007 15:14:15 -0400 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <20070808185922.GA30644@nostromo.devel.redhat.com> References: <46BA08C1.6050101@redhat.com> <20070808182146.GC32146@nostromo.devel.redhat.com> <20070808134327.10d8ba4f@weaponx.rchland.ibm.com> <46BA11A0.3000402@redhat.com> <20070808185922.GA30644@nostromo.devel.redhat.com> Message-ID: <20070808191415.GA5001@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > I think it should be added to /etc/sysconfig/modules > > Has any one actually diagnosed how it got loaded before, and why > that stopped working? So, try the following: On an old working box - - in one terminal, run udevmonitor --env --kernel - in the other, run 'udevtriger --verbose --subsystem-match=platform' You'll see an event (among others) for /devices/platform/pcspkr On a new, non working box, do the same. You won't see the event for pcspkr. However, /sys/devices/platform/pcspkr is still there, with the same setup. Ergo, the kernel is broken, and that's where the fix should be. Bill From cebbert at redhat.com Wed Aug 8 20:40:28 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 08 Aug 2007 16:40:28 -0400 Subject: New Intel e1000 device support Message-ID: <46BA2A3C.7010901@redhat.com> I just put Intel's latest cut at ICH9 e1000 support into rawhide, removing the preliminary hack that backported the support into the old driver. Since this new one *only* supports ICH9, it looks pretty safe to put it into Fedora 6 and 7 as well. Comments? From jwilson at redhat.com Wed Aug 8 20:47:20 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 08 Aug 2007 16:47:20 -0400 Subject: New Intel e1000 device support In-Reply-To: <46BA2A3C.7010901@redhat.com> References: <46BA2A3C.7010901@redhat.com> Message-ID: <46BA2BD8.1070100@redhat.com> Chuck Ebbert wrote: > I just put Intel's latest cut at ICH9 e1000 support into rawhide, > removing the preliminary hack that backported the support into > the old driver. Since this new one *only* supports ICH9, it looks > pretty safe to put it into Fedora 6 and 7 as well. Comments? Assuming there are no pci device id overlap w/the older driver, it shouldn't break anything already working, so it really can't cause any regressions. I'd say do it. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davej at redhat.com Thu Aug 9 02:50:26 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Aug 2007 22:50:26 -0400 Subject: MSI and MMCONFIG, again... In-Reply-To: <46BA0065.5020703@redhat.com> References: <46B9F689.6040506@redhat.com> <46B9FD5A.7030303@redhat.com> <46BA0065.5020703@redhat.com> Message-ID: <20070809025026.GA5414@redhat.com> On Wed, Aug 08, 2007 at 01:41:57PM -0400, Chuck Ebbert wrote: > On 08/08/2007 01:28 PM, Prarit Bhargava wrote: > >> We are still hitting problems with MSI (and probably mmconfig) > >> with kernel 2.6.22: > >> > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 > >> > >> Should we just go back to disabling these by default? > >> > > > > Chuck -- how long have we had this re-enabled? What about (groan) doing > > quirks for msi/mmconfig? > > > > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. > > And there are quirks in there now, I guess the list just isn't complete > (and probably never can be.) Weren't there other newer devices that need MSI on ? Some of the infiniband stuff maybe? As painful as it is, additional quirks would be the best all-round solution I think. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Aug 9 10:55:06 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 03:55:06 -0700 (PDT) Subject: e1000e vs ppc Message-ID: <20070809105506.815634D04C4@magilla.localdomain> The e1000e patch seems to have broken ppc builds. I disabled it %ifarch (I know, bad) just for the moment so I could try to get a build to finish with my other commits. It needs a proper fix. Thanks, Roland From oliver at linux-kernel.at Thu Aug 9 11:31:24 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 09 Aug 2007 13:31:24 +0200 Subject: Alpha support for kernel In-Reply-To: <20070809112329.E00A94D04C5@magilla.localdomain> References: <20070809112329.E00A94D04C5@magilla.localdomain> Message-ID: <46BAFB0C.9080907@linux-kernel.at> Hi! I would like to finally add alpha support to our kernel cvs. I will provide all relavant configs and patches within this mail and hope someone will take care of that. alpha.patch is the main thing, that actually does the patching of the spec and the Makefile.config. Please have a look at it, revert back to me in case something isn't as you like it... Best, Oliver -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.6.21-alpha_execshield.patch Type: text/x-patch Size: 539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.6.21-alpha_pagesize.patch Type: text/x-patch Size: 500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: alpha.patch Type: text/x-patch Size: 4866 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config-alpha URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config-alpha-smp URL: From roland at redhat.com Thu Aug 9 11:59:11 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 04:59:11 -0700 (PDT) Subject: Alpha support for kernel In-Reply-To: Oliver Falk's message of Thursday, 9 August 2007 13:31:24 +0200 <46BAFB0C.9080907@linux-kernel.at> Message-ID: <20070809115911.E703A4D04C9@magilla.localdomain> You should define define an all_alpha spec macro for alpha alphaev56. From oliver at linux-kernel.at Thu Aug 9 12:06:23 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 09 Aug 2007 14:06:23 +0200 Subject: Alpha support for kernel In-Reply-To: <20070809115911.E703A4D04C9@magilla.localdomain> References: <20070809115911.E703A4D04C9@magilla.localdomain> Message-ID: <46BB033F.8000109@linux-kernel.at> On 08/09/2007 01:59 PM, Roland McGrath wrote: > You should define define an all_alpha spec macro for alpha alphaev56. Well. I just use it the way it was in the existing spec to not blow it up too much. However, if I would do so, it would be better to %define all_alpha alpha alphaev5 alphaev56 alphapca56 alpha6 alpha67 I took the above from rpmrc. I see in rpm/macros ix86 defined and arm as well - maybe we should add alpha there as well, but that's another story... -of From gilboad at gmail.com Thu Aug 9 12:57:57 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 09 Aug 2007 15:57:57 +0300 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <1186597332.18415.1.camel@mentos.hsv.redhat.com> References: <46BA08C1.6050101@redhat.com> <1186597332.18415.1.camel@mentos.hsv.redhat.com> Message-ID: <1186664277.21049.5.camel@gilboa-work-dev.localdomain> On Wed, 2007-08-08 at 13:22 -0500, Guy Streeter wrote: > On Wed, 2007-08-08 at 14:17 -0400, Chuck Ebbert wrote: > > The pcspkr driver doesn't load automatically any more with kernel > > 2.6.22. > > > > Should we build it in, or maybe add it to the list of drivers that > > always get loaded? > > Please don't build it in. I disable the module on every machine I use. > / +1 - Gilboa From snecklifter at gmail.com Thu Aug 9 13:57:07 2007 From: snecklifter at gmail.com (Chris Brown) Date: Thu, 9 Aug 2007 14:57:07 +0100 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <1186664277.21049.5.camel@gilboa-work-dev.localdomain> References: <46BA08C1.6050101@redhat.com> <1186597332.18415.1.camel@mentos.hsv.redhat.com> <1186664277.21049.5.camel@gilboa-work-dev.localdomain> Message-ID: <364d303b0708090657w62ec0c74kc67f7ba9e0cc8086@mail.gmail.com> On 09/08/07, Gilboa Davara wrote: > On Wed, 2007-08-08 at 13:22 -0500, Guy Streeter wrote: > > On Wed, 2007-08-08 at 14:17 -0400, Chuck Ebbert wrote: > > > The pcspkr driver doesn't load automatically any more with kernel > > > 2.6.22. > > > > > > Should we build it in, or maybe add it to the list of drivers that > > > always get loaded? > > > > Please don't build it in. I disable the module on every machine I use. > > > > / +1 This has been discussed before. I also hate it with a passion however as I understand it the pcspkr is a core part of accessibility for users with poor/no sight. Chris -- http://www.chruz.com From gilboad at gmail.com Thu Aug 9 14:02:59 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 09 Aug 2007 17:02:59 +0300 Subject: Should we just build the pcspkr driver into the X86 kernels? In-Reply-To: <364d303b0708090657w62ec0c74kc67f7ba9e0cc8086@mail.gmail.com> References: <46BA08C1.6050101@redhat.com> <1186597332.18415.1.camel@mentos.hsv.redhat.com> <1186664277.21049.5.camel@gilboa-work-dev.localdomain> <364d303b0708090657w62ec0c74kc67f7ba9e0cc8086@mail.gmail.com> Message-ID: <1186668179.21049.9.camel@gilboa-work-dev.localdomain> On Thu, 2007-08-09 at 14:57 +0100, Chris Brown wrote: > On 09/08/07, Gilboa Davara wrote: > > On Wed, 2007-08-08 at 13:22 -0500, Guy Streeter wrote: > > > On Wed, 2007-08-08 at 14:17 -0400, Chuck Ebbert wrote: > > > > The pcspkr driver doesn't load automatically any more with kernel > > > > 2.6.22. > > > > > > > > Should we build it in, or maybe add it to the list of drivers that > > > > always get loaded? > > > > > > Please don't build it in. I disable the module on every machine I use. > > > > > > > / +1 > > This has been discussed before. I also hate it with a passion however > as I understand it the pcspkr is a core part of accessibility for > users with poor/no sight. > > Chris > ... I have no problem with it being installed/enabled by default as long as I can disable it with ease. - Gilboa From davej at redhat.com Thu Aug 9 17:05:26 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 9 Aug 2007 13:05:26 -0400 Subject: Alpha support for kernel In-Reply-To: <46BAFB0C.9080907@linux-kernel.at> References: <20070809112329.E00A94D04C5@magilla.localdomain> <46BAFB0C.9080907@linux-kernel.at> Message-ID: <20070809170526.GB19780@redhat.com> On Thu, Aug 09, 2007 at 01:31:24PM +0200, Oliver Falk wrote: > -# sparse blows up on ppc64 > +# sparse blows up on ppc64 and alpha > %ifarch ppc64 ppc alpha > %define usesparse 0 > %endif Got bug report? Actually I should re-test ppc, that may be fixed now. > +Patch1101: linux-2.6.21-alpha_execshield.patch > +Patch1102: linux-2.6.21-alpha_pagesize.patch These should drop the '21' in the filename. (Actually, I'll just fold them into the execshield patch) > # Exec shield > +# Doesn't work on alpha :-( > +%ifnarch alpha alphaev56 > ApplyPatch linux-2.6-execshield.patch > +%endif Oh. Hmm, maybe not. > +# Alpha patches > +ApplyPatch linux-2.6.21-alpha_execshield.patch > +ApplyPatch linux-2.6.21-alpha_pagesize.patch So this is odd. It'd be better to fold your diffs into the execshield patch, and make that build, even if it doesn't actually use any of the execshield functionality. > CONFIG_ALPHA=y > CONFIG_64BIT=y > ... This should use the templated files and just override config-generic where necessary. This way we don't need to change options in N places when something changes. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Thu Aug 9 19:36:54 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 09 Aug 2007 15:36:54 -0400 Subject: MSI and MMCONFIG, again... In-Reply-To: <20070809025026.GA5414@redhat.com> References: <46B9F689.6040506@redhat.com> <46B9FD5A.7030303@redhat.com> <46BA0065.5020703@redhat.com> <20070809025026.GA5414@redhat.com> Message-ID: <46BB6CD6.6010301@redhat.com> On 08/08/2007 10:50 PM, Dave Jones wrote: > On Wed, Aug 08, 2007 at 01:41:57PM -0400, Chuck Ebbert wrote: > > On 08/08/2007 01:28 PM, Prarit Bhargava wrote: > > >> We are still hitting problems with MSI (and probably mmconfig) > > >> with kernel 2.6.22: > > >> > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 > > >> > > >> Should we just go back to disabling these by default? > > >> > > > > > > Chuck -- how long have we had this re-enabled? What about (groan) doing > > > quirks for msi/mmconfig? > > > > > > > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. > > > > And there are quirks in there now, I guess the list just isn't complete > > (and probably never can be.) > > Weren't there other newer devices that need MSI on ? > Some of the infiniband stuff maybe? > > As painful as it is, additional quirks would be the best all-round > solution I think. > I think it would be best to turn MSI off in FC6, where it's already been off for a long time anyway. From davej at redhat.com Thu Aug 9 19:41:45 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 9 Aug 2007 15:41:45 -0400 Subject: MSI and MMCONFIG, again... In-Reply-To: <46BB6CD6.6010301@redhat.com> References: <46B9F689.6040506@redhat.com> <46B9FD5A.7030303@redhat.com> <46BA0065.5020703@redhat.com> <20070809025026.GA5414@redhat.com> <46BB6CD6.6010301@redhat.com> Message-ID: <20070809194145.GA31508@redhat.com> On Thu, Aug 09, 2007 at 03:36:54PM -0400, Chuck Ebbert wrote: > On 08/08/2007 10:50 PM, Dave Jones wrote: > > On Wed, Aug 08, 2007 at 01:41:57PM -0400, Chuck Ebbert wrote: > > > On 08/08/2007 01:28 PM, Prarit Bhargava wrote: > > > >> We are still hitting problems with MSI (and probably mmconfig) > > > >> with kernel 2.6.22: > > > >> > > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249469 > > > >> > > > >> Should we just go back to disabling these by default? > > > >> > > > > > > > > Chuck -- how long have we had this re-enabled? What about (groan) doing > > > > quirks for msi/mmconfig? > > > > > > > > > > They were re-enabled with the new 2.6.22 kernels for Fedora 6 and 7. > > > > > > And there are quirks in there now, I guess the list just isn't complete > > > (and probably never can be.) > > > > Weren't there other newer devices that need MSI on ? > > Some of the infiniband stuff maybe? > > > > As painful as it is, additional quirks would be the best all-round > > solution I think. > > > > I think it would be best to turn MSI off in FC6, where it's already been off > for a long time anyway. Might be useful to do that as a comparison too. If a bug goes away on FC6, and sticks around on later releases, whilst we're on the same codebase, we should be able to spot MSI failures a little easier. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Aug 9 20:32:34 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 13:32:34 -0700 (PDT) Subject: macroized spec committed Message-ID: <20070809203234.BF1B54D04CB@magilla.localdomain> I put in the macroified kernel.spec last night. It also has some new magic changes to play well with the new find-debuginfo.sh. It hasn't built yet since I threw in some other broken changes at the same time, which are probably fixed by now for the next build Dave does. I made the bits that expect the new find-debuginfo.sh conditional on %fedora>7. So it probably will still work in [67] if you do later updates by plopping in the F8 spec. But I haven't really sanity-checked it for that case. Thanks, Roland From roland at redhat.com Thu Aug 9 20:59:49 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 13:59:49 -0700 (PDT) Subject: pre-release kernel release tag Message-ID: <20070809205949.7F11C4D0461@magilla.localdomain> I propose we change the release format for snapshot kernels. Now we get e.g.: kernel-2.6.23-0.89.rc2.git2.fc8 and I suggest instead: kernel-2.6.23-0.rc2.git2.89.fc8 That is, put the spec file version number last, not first. This way, when we forget to reset fedora_cvs_origin after a rebase, we don't have to wait for the next kernel version to do it, just the next gitN. We can't make this change until 2.6.23 sails, since for rpm version comparison rc* is < any [0-9]. --- kernel.spec 09 Aug 2007 13:45:09 -0700 1.72 +++ kernel.spec 09 Aug 2007 13:46:42 -0700 @@ -126,7 +126,7 @@ Summary: The Linux kernel (the core of t %define rctag .rc0 %endif %endif -%define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist} +%define pkg_release 0%{?rctag}%{?gittag}.%{fedora_build}%{?buildid}%{?dist} %endif # The kernel tarball/base version From tcallawa at redhat.com Thu Aug 9 21:03:15 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 09 Aug 2007 17:03:15 -0400 Subject: pre-release kernel release tag In-Reply-To: <20070809205949.7F11C4D0461@magilla.localdomain> References: <20070809205949.7F11C4D0461@magilla.localdomain> Message-ID: <1186693395.4096.5.camel@localhost.localdomain> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > I propose we change the release format for snapshot kernels. > Now we get e.g.: > > kernel-2.6.23-0.89.rc2.git2.fc8 > > and I suggest instead: > > kernel-2.6.23-0.rc2.git2.89.fc8 > > That is, put the spec file version number last, not first. This way, when > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > for the next kernel version to do it, just the next gitN. > > We can't make this change until 2.6.23 sails, since for rpm version > comparison rc* is < any [0-9]. Please don't do this. The kernel package is finally compliant with the Fedora Packaging Guidelines and this change would break it again. The reason we prefix with the 0.# is to prevent versioning comparison madness. If you need to do a fast rebuild, append a .# after the %{?dist}. ~spot From davej at redhat.com Thu Aug 9 21:11:19 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 9 Aug 2007 17:11:19 -0400 Subject: pre-release kernel release tag In-Reply-To: <20070809205949.7F11C4D0461@magilla.localdomain> References: <20070809205949.7F11C4D0461@magilla.localdomain> Message-ID: <20070809211119.GA15084@redhat.com> On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > I propose we change the release format for snapshot kernels. > Now we get e.g.: > > kernel-2.6.23-0.89.rc2.git2.fc8 > > and I suggest instead: > > kernel-2.6.23-0.rc2.git2.89.fc8 > > That is, put the spec file version number last, not first. This way, when > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > for the next kernel version to do it, just the next gitN. Is it that big a deal? I intended to only reset the origin after each point release, so it doesn't really buy us anything being able to change this with every -git. Dave -- http://www.codemonkey.org.uk From roland at redhat.com Thu Aug 9 21:21:47 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 14:21:47 -0700 (PDT) Subject: pre-release kernel release tag In-Reply-To: "Tom \"spot\" Callaway"'s message of Thursday, 9 August 2007 17:03:15 -0400 <1186693395.4096.5.camel@localhost.localdomain> Message-ID: <20070809212147.BA0984D0461@magilla.localdomain> > > On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > for the next kernel version to do it, just the next gitN. > > > > We can't make this change until 2.6.23 sails, since for rpm version > > comparison rc* is < any [0-9]. > > Please don't do this. The kernel package is finally compliant with the > Fedora Packaging Guidelines and this change would break it again. > > The reason we prefix with the 0.# is to prevent versioning comparison > madness. What? I didn't propose removing the 0. prefix. What is the problem? From roland at redhat.com Thu Aug 9 21:24:44 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Aug 2007 14:24:44 -0700 (PDT) Subject: pre-release kernel release tag In-Reply-To: Dave Jones's message of Thursday, 9 August 2007 17:11:19 -0400 <20070809211119.GA15084@redhat.com> Message-ID: <20070809212444.A0CB64D0461@magilla.localdomain> > On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > > I propose we change the release format for snapshot kernels. > > Now we get e.g.: > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > and I suggest instead: > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > That is, put the spec file version number last, not first. This way, when > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > for the next kernel version to do it, just the next gitN. > > Is it that big a deal? I intended to only reset the origin after each > point release, so it doesn't really buy us anything being able to change > this with every -git. It's not a big deal, it's only numbers. The motivation was that it didn't get reset when we went from 2.6.22 to 2.6.23, and after one build hits rawhide, it's too late. Also, it's just better because it accurately reflects the topology of change. A spec release is a variant of a kernel snapshot, not vice versa. From davej at redhat.com Thu Aug 9 21:54:53 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 9 Aug 2007 17:54:53 -0400 Subject: pre-release kernel release tag In-Reply-To: <20070809212444.A0CB64D0461@magilla.localdomain> References: <20070809211119.GA15084@redhat.com> <20070809212444.A0CB64D0461@magilla.localdomain> Message-ID: <20070809215453.GA3583@redhat.com> On Thu, Aug 09, 2007 at 02:24:44PM -0700, Roland McGrath wrote: > > On Thu, Aug 09, 2007 at 01:59:49PM -0700, Roland McGrath wrote: > > > I propose we change the release format for snapshot kernels. > > > Now we get e.g.: > > > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > > > and I suggest instead: > > > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > > > That is, put the spec file version number last, not first. This way, when > > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > > for the next kernel version to do it, just the next gitN. > > > > Is it that big a deal? I intended to only reset the origin after each > > point release, so it doesn't really buy us anything being able to change > > this with every -git. > > It's not a big deal, it's only numbers. The motivation was that it didn't > get reset when we went from 2.6.22 to 2.6.23, and after one build hits > rawhide, it's too late. For rawhide, I don't think it really matters too much. Dave -- http://www.codemonkey.org.uk From cebbert at redhat.com Thu Aug 9 22:05:35 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 09 Aug 2007 18:05:35 -0400 Subject: Trying to add s390 arch build back to FC-6 failed Message-ID: <46BB8FAF.8040606@redhat.com> What did I miss? Not only did I not get s390 to build, somehow I broke s390x as well. It doesn't even submit the build jobs... Index: kernel-2.6.spec =================================================================== RCS file: /cvs/dist/rpms/kernel/FC-6/kernel-2.6.spec,v retrieving revision 1.3003 retrieving revision 1.3004 diff -u -r1.3003 -r1.3004 --- kernel-2.6.spec 9 Aug 2007 21:01:34 -0000 1.3003 +++ kernel-2.6.spec 9 Aug 2007 21:26:49 -0000 1.3004 @@ -20,7 +20,7 @@ # kernel spec when the kernel is rebased, so fedora_build automatically # works out to the offset from the rebase, so it doesn't get too ginormous. %define fedora_cvs_origin 2968 -%define fedora_build %(R="$Revision: 1.3003 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) +%define fedora_build %(R="$Revision: 1.3004 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) # base_sublevel is the kernel version we're starting with and patching # on top of -- for example, 2.6.22-rc7-git1 starts with a 2.6.21 base, @@ -247,7 +247,7 @@ %endif # don't sign modules on these platforms -%ifarch s390x sparc sparc64 ppc alpha +%ifarch s390 s390x sparc sparc64 ppc alpha %define with_modsign 0 %endif @@ -280,6 +280,13 @@ %define hdrarch powerpc %endif +%ifarch s390 +%define all_arch_configs $RPM_SOURCE_DIR/kernel-%{version}-s390.config +%define image_install_path boot +%define make_target image +%define kernel_image arch/s390/boot/image +%endif + %ifarch s390x %define all_arch_configs $RPM_SOURCE_DIR/kernel-%{version}-s390x.config %define image_install_path boot @@ -396,7 +403,7 @@ Release: %{pkg_release} # DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD. # SET %nobuildarches (ABOVE) INSTEAD -ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390x alpha alphaev56 +ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ia64 sparc sparc64 s390 s390x alpha alphaev56 ExclusiveOS: Linux Provides: kernel-drm = 4.3.0 Provides: kernel-drm-nouveau = 6 @@ -449,7 +456,8 @@ Source30: kernel-%{version}-ppc64.config Source31: kernel-%{version}-ppc64-kdump.config -Source35: kernel-%{version}-s390x.config +Source35: kernel-%{version}-s390.config +Source36: kernel-%{version}-s390x.config Source36: kernel-%{version}-ia64.config @@ -2263,6 +2271,10 @@ %changelog * Thu Aug 09 2007 Chuck Ebbert +- hopefully add s390 back to the build + (ugly hack, s390 overrides s390x, no -generic used) + +* Thu Aug 09 2007 Chuck Ebbert - disable CONFIG_SCSI_SCAN_ASYNC * Thu Aug 09 2007 Chuck Ebbert From ehabkost at redhat.com Thu Aug 9 22:13:16 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Thu, 9 Aug 2007 19:13:16 -0300 Subject: Trying to add s390 arch build back to FC-6 failed In-Reply-To: <46BB8FAF.8040606@redhat.com> References: <46BB8FAF.8040606@redhat.com> Message-ID: <20070809221315.GC3728@blackpad.ctb.virtua.com.br> On Thu, Aug 09, 2007 at 06:05:35PM -0400, Chuck Ebbert wrote: > What did I miss? > > Not only did I not get s390 to build, somehow I broke s390x as well. > It doesn't even submit the build jobs... The only problem is that the build jobs for s390 aren't even starting anymore, or is it failing in other ways? If I understdood correctly, s390 was removed from the FC-6 buildroot arch list on Brew today. So probably s390 won't build anymore. It seems that it was supposed to be disabled a long time ago. -- Eduardo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cebbert at redhat.com Thu Aug 9 22:17:06 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Thu, 09 Aug 2007 18:17:06 -0400 Subject: Trying to add s390 arch build back to FC-6 failed In-Reply-To: <20070809221315.GC3728@blackpad.ctb.virtua.com.br> References: <46BB8FAF.8040606@redhat.com> <20070809221315.GC3728@blackpad.ctb.virtua.com.br> Message-ID: <46BB9262.2050902@redhat.com> On 08/09/2007 06:13 PM, Eduardo Habkost wrote: > On Thu, Aug 09, 2007 at 06:05:35PM -0400, Chuck Ebbert wrote: >> What did I miss? >> >> Not only did I not get s390 to build, somehow I broke s390x as well. >> It doesn't even submit the build jobs... > > The only problem is that the build jobs for s390 aren't even starting > anymore, or is it failing in other ways? > > If I understdood correctly, s390 was removed from the FC-6 buildroot > arch list on Brew today. So probably s390 won't build anymore. It seems > that it was supposed to be disabled a long time ago. Well I guess the headers aren't needed anymore then. Never mind. :) From Axel.Thimm at ATrpms.net Fri Aug 10 00:07:05 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 10 Aug 2007 02:07:05 +0200 Subject: pre-release kernel release tag In-Reply-To: <20070809212147.BA0984D0461@magilla.localdomain> References: <1186693395.4096.5.camel@localhost.localdomain> <20070809212147.BA0984D0461@magilla.localdomain> Message-ID: <20070810000705.GA13668@puariko.nirvana> On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote: > > > > On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: > > > I propose we change the release format for snapshot kernels. > > > Now we get e.g.: > > > > > > kernel-2.6.23-0.89.rc2.git2.fc8 > > > > > > and I suggest instead: > > > > > > kernel-2.6.23-0.rc2.git2.89.fc8 > > > > > > That is, put the spec file version number last, not first. This way, when > > > we forget to reset fedora_cvs_origin after a rebase, we don't have to wait > > > for the next kernel version to do it, just the next gitN. > > > > > > We can't make this change until 2.6.23 sails, since for rpm version > > > comparison rc* is < any [0-9]. > > > > Please don't do this. The kernel package is finally compliant with the > > Fedora Packaging Guidelines and this change would break it again. > > > > The reason we prefix with the 0.# is to prevent versioning comparison > > madness. > > What? I didn't propose removing the 0. prefix. What is the problem? Look closer, there's a `#? in Tom's reply, which is what you want to move away. Actually the 0. prefix is not neccessary it is a leftover from 3rd party techniques to indicate vendor hierarchies, but it's difficult to knock out people's head. The important bit is that by having the `#? before the part-of-the- version-that-had-to-be-banned-to-the-release-tag-because-otherwise-the- version-would-not-properly-increment you become independent of any upstream versioning trickery. git/rc versioning is not that new, and who knows whether next year we'll have pre/rc/gold/ga/pl madness in upstream sub-versioning. So please keep the buildtag as `#? is often referred to before the part-of-the-version-that-had-to-be-banned -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri Aug 10 03:22:08 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 09 Aug 2007 23:22:08 -0400 Subject: pre-release kernel release tag In-Reply-To: <20070810000705.GA13668@puariko.nirvana> References: <1186693395.4096.5.camel@localhost.localdomain> <20070809212147.BA0984D0461@magilla.localdomain> <20070810000705.GA13668@puariko.nirvana> Message-ID: <46BBD9E0.9030405@redhat.com> Axel Thimm wrote: > On Thu, Aug 09, 2007 at 02:21:47PM -0700, Roland McGrath wrote: >>> On Thu, 2007-08-09 at 13:59 -0700, Roland McGrath wrote: >>>> I propose we change the release format for snapshot kernels. >>>> Now we get e.g.: >>>> >>>> kernel-2.6.23-0.89.rc2.git2.fc8 >>>> >>>> and I suggest instead: >>>> >>>> kernel-2.6.23-0.rc2.git2.89.fc8 >>>> >>>> That is, put the spec file version number last, not first. This way, when >>>> we forget to reset fedora_cvs_origin after a rebase, we don't have to wait >>>> for the next kernel version to do it, just the next gitN. >>>> >>>> We can't make this change until 2.6.23 sails, since for rpm version >>>> comparison rc* is < any [0-9]. >>> Please don't do this. The kernel package is finally compliant with the >>> Fedora Packaging Guidelines and this change would break it again. >>> >>> The reason we prefix with the 0.# is to prevent versioning comparison >>> madness. >> What? I didn't propose removing the 0. prefix. What is the problem? > > Look closer, there's a `#? in Tom's reply, which is what you want to > move away. Actually the 0. prefix is not neccessary it is a leftover > from 3rd party techniques to indicate vendor hierarchies, but it's > difficult to knock out people's head. It has nothing to do with any 3rd-party techniques in the case. The '0.#' instead of just '#' is so that we can rebase the release number to 1 on each new major kernel version, so the first released 2.6.23 kernel for fc8 will be 2.6.23-1.fc8. At least, that was my intention when I wrote this stuff up, and its how we've used it thus far. Of course, my initial thought had been it'd be nice to not even have the '.#' portion in there, since you get reasonably decent rpm ordering with just 0.rcX.gitY.fc8, but then if we end up doing a rebuild of the same git snap, you have to worry about it, but we don't want to have to muck around with that manually. That being the case, putting it after the leading 0 for git snaps, automatically incremented over the period leading up to the next kernel release, in line with the packaging guidelines, made the most sense. -- Jarod Wilson jwilson at redhat.com From Axel.Thimm at ATrpms.net Fri Aug 10 06:50:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 10 Aug 2007 08:50:39 +0200 Subject: pre-release kernel release tag In-Reply-To: <46BBD9E0.9030405@redhat.com> References: <1186693395.4096.5.camel@localhost.localdomain> <20070809212147.BA0984D0461@magilla.localdomain> <20070810000705.GA13668@puariko.nirvana> <46BBD9E0.9030405@redhat.com> Message-ID: <20070810065039.GA25328@puariko.nirvana> On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote: > >Actually the 0. prefix is not neccessary it is a leftover from 3rd > >party techniques to indicate vendor hierarchies, but it's difficult > >to knock out people's head. > > It has nothing to do with any 3rd-party techniques in the case. The > '0.#' instead of just '#' is so that we can rebase the release number to > 1 on each new major kernel version, It has everything to do with 3rd parties and the key element here is history: Many years ago we started to discuss the beginning of what today became the packaging guidelines in fedora.us. One element was what to do with packages that override the vendors' (RHL 6.x/7.x at that time), especially when the vendor was shippijng foo-1 and one would like to use foo-3. So foo-3-0.whatever was considered as a hierachy solution to allow the vendor to catch up with the 3rd party package w/o the vendor having to coordinate build tags with the little 3rd party repos. In reality many foo-1 -> foo-3 upgrades were for foo-3 = some prerelease, so this idiom got confused for prepending a 0. to prereleases. So, "0." had a semantic wandering to land where it's used now, and the beginnings were 3rd party techniques to auto-overide their own packages when the vendor would update his. ;) There is nothing wrong with not using "0." to mark prereleases, it's just Fedora legacy/tradition. I'm not a fan of resetting the build tag anyway. But whatever the "0." the important thing is that the build tag (`#?) remains in front even if today the sub-versioning scheme for the kernel looks like it would automatically happen to fit in rpmvercmp ordering. Another history lesson shows that once one thought a versioning style would settle and work it is "usefully" extended in a way as to break theis assumption ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri Aug 10 14:06:16 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 10 Aug 2007 10:06:16 -0400 Subject: pre-release kernel release tag In-Reply-To: <20070810065039.GA25328@puariko.nirvana> References: <1186693395.4096.5.camel@localhost.localdomain> <20070809212147.BA0984D0461@magilla.localdomain> <20070810000705.GA13668@puariko.nirvana> <46BBD9E0.9030405@redhat.com> <20070810065039.GA25328@puariko.nirvana> Message-ID: <46BC70D8.100@redhat.com> Axel Thimm wrote: > On Thu, Aug 09, 2007 at 11:22:08PM -0400, Jarod Wilson wrote: >>> Actually the 0. prefix is not neccessary it is a leftover from 3rd >>> party techniques to indicate vendor hierarchies, but it's difficult >>> to knock out people's head. >> It has nothing to do with any 3rd-party techniques in the case. The >> '0.#' instead of just '#' is so that we can rebase the release number to >> 1 on each new major kernel version, > > It has everything to do with 3rd parties and the key element here is > history: Many years ago we started to discuss the beginning of what > today became the packaging guidelines in fedora.us. One element was > what to do with packages that override the vendors' (RHL 6.x/7.x at > that time), especially when the vendor was shippijng foo-1 and one > would like to use foo-3. > > So foo-3-0.whatever was considered as a hierachy solution to allow the > vendor to catch up with the 3rd party package w/o the vendor having to > coordinate build tags with the little 3rd party repos. > > In reality many foo-1 -> foo-3 upgrades were for foo-3 = some > prerelease, so this idiom got confused for prepending a 0. to > prereleases. > > So, "0." had a semantic wandering to land where it's used now, and the > beginnings were 3rd party techniques to auto-overide their own > packages when the vendor would update his. > ;) Yes, there's history behind why the "0." convention is in the packaging guidelines, but I still maintain that the 3rd-party history has/had zero bearing on the decision to use it in the kernel package. > There is nothing wrong with not using "0." to mark prereleases, it's > just Fedora legacy/tradition. I'm not a fan of resetting the build tag > anyway. I think your distaste of resetting the build tag is the real sticking point here. The main reason for "0." in pre-release versioning is because the majority of people *are* fans of resetting the build tag. > But whatever the "0." the important thing is that the build tag (`#?) > remains in front even if today the sub-versioning scheme for the > kernel looks like it would automatically happen to fit in rpmvercmp > ordering. Another history lesson shows that once one thought a > versioning style would settle and work it is "usefully" extended in a > way as to break theis assumption ;) True, true... rh9 -> fc1, fc6 -> f7... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Sun Aug 12 11:00:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Aug 2007 13:00:41 +0200 Subject: pre-release kernel release tag In-Reply-To: <20070809212444.A0CB64D0461@magilla.localdomain> References: <20070809212444.A0CB64D0461@magilla.localdomain> Message-ID: <1186916441.7718.2.camel@rousalka.dyndns.org> Le jeudi 09 ao?t 2007 ? 14:24 -0700, Roland McGrath a ?crit : > Also, it's just better because it accurately > reflects the topology of change. A spec release is a variant of a kernel > snapshot, not vice versa. Good version ordering is more important than topology Snapshot names are not always ordered, Fedora shiped non-Linus kernels in the past (-ac...), etc -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roland at redhat.com Tue Aug 14 06:16:29 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 13 Aug 2007 23:16:29 -0700 (PDT) Subject: modsign vs build-id Message-ID: <20070814061629.1F9794D057D@magilla.localdomain> I fixed this in rawhide kernel.spec over the weekend and left a somewhat detailed comment in the changed bit. But I thought I'd bring this up directly and explain the story. The short version of What Broke is "what, you sha1 on me? no, i sha1 on you!" Module signing works by feeding all the allocated sections of the .ko into gpg and adding that signature to the .ko as the .module_sig section. The build ID note now included in each .ko when first built is an allocated section, so its contents contribute to that signature. As explained somewhere down the middle of [1], debugedit (the workhorse of find-debuginfo.sh) recomputes fresh build ID bits after editting the debuginfo, and edits the build ID bits in the object. This final build ID is computed with sha1 on most of the contents of the editted binary (including debuginfo). It's done this way to ensure that repeating the same rpmbuild twice with all the same constituents in the buildroot yields identical binaries both times (with the same build IDs), unaffected by the differences that debugedit removes, like the $RPM_BUILD_DIR name. In the old procedure, the modules were signed in place after being built. Then find-debuginfo.sh comes along at the end of the build, and edits the build ID bits in each .ko. Pow, the signature does not match the contents. The first fix I tried was changing module signing and verification so it skips allocated SHT_NOTE sections, which the build ID is. That worked. But that is not so hot in two ways. One, the signature is not serving as guarantor of the trustability of the module->build ID association. Worse, since the final build ID bits depend on everything in the installed .ko--including the .module_sig section--now repeated builds get different build IDs for the identical code compiled from identical sources. So I punted that. What kernel.spec now does is to sign the stripped .ko files only at the very end, after find-debuginfo.sh has done its work. This requires some spec macro hackery to get in at the right spot. Now a repeated build will still generate a new module-signing key and different signatures every time. But the build ID bits inside the signed modules will be the same every time. Now you know if a module got loaded with no unsigned taint, then the build ID bits it claims to have really are those the kernel packager wanted you to see. (Not that this is worth a lot.) Incidentally, if someone wants to freshen up the modsign patches, I think it would be better to change the format slightly. Thanks, Roland [1] http://fedoraproject.org/wiki/RolandMcGrath/BuildID From prarit at redhat.com Tue Aug 14 14:21:05 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Tue, 14 Aug 2007 10:21:05 -0400 Subject: Anyone else? Message-ID: <46C1BA51.10009@redhat.com> Is anyone else seeing this when scp'ing INTO a box with F8T1 or newer kernels? x86_64, intel 4-way .... BUG: warning at kernel/softirq.c:138/local_bh _enable() (Not tainted) Call Trace: [] show_stack+0x40/0xa0 sp=e0000040f39b7ac0 bsp=e0000040f39b1090 [] dump_stack+0x30/0x60 sp=e0000040f39b7c90 bsp=e0000040f39b1078 [] local_bh_enable+0xb0/0x180 sp=e0000040f39b7c90 bsp=e0000040f39b1058 [] cond_resched_softirq+0xf0/0x160 sp=e0000040f39b7c90 bsp=e0000040f39b1040 [] release_sock+0x100/0x1c0 sp=e0000040f39b7c90 bsp=e0000040f39b1010 [] tcp_sendmsg+0x1a00/0x1ca0 sp=e0000040f39b7c90 bsp=e0000040f39b0f58 [] inet_sendmsg+0xd0/0x100 sp=e0000040f39b7ca0 bsp=e0000040f39b0f20 [] sock_aio_write+0x280/0x2e0 sp=e0000040f39b7ca0 bsp=e0000040f39b0ed0 [] do_sync_write+0x180/0x200 sp=e0000040f39b7d20 bsp=e0000040f39b0e98 [] vfs_write+0x230/0x3a0 sp=e0000040f39b7e20 bsp=e0000040f39b0e48 [] sys_write+0x70/0xe0 sp=e0000040f39b7e20 bsp=e0000040f39b0dc8 [] ia64_trace_syscall+0xd0/0x110 sp=e0000040f39b7e30 bsp=e0000040f39b0dc8 [] __kernel_syscall_via_break+0x0/0x20 sp=e0000040f39b8000 bsp=e0000040f39b0dc8 From prarit at redhat.com Tue Aug 14 14:22:41 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Tue, 14 Aug 2007 10:22:41 -0400 Subject: Anyone else? In-Reply-To: <46C1BA51.10009@redhat.com> References: <46C1BA51.10009@redhat.com> Message-ID: <46C1BAB1.9090101@redhat.com> Prarit Bhargava wrote: > Is anyone else seeing this when scp'ing INTO a box with F8T1 or newer > kernels? x86_64, intel 4-way .... > D'oh! I meant ia64 :) P. > > BUG: warning at kernel/softirq.c:138/local_bh > _enable() (Not tainted) > > Call Trace: > [] show_stack+0x40/0xa0 > sp=e0000040f39b7ac0 bsp=e0000040f39b1090 > [] dump_stack+0x30/0x60 > sp=e0000040f39b7c90 bsp=e0000040f39b1078 > [] local_bh_enable+0xb0/0x180 > sp=e0000040f39b7c90 bsp=e0000040f39b1058 > [] cond_resched_softirq+0xf0/0x160 > sp=e0000040f39b7c90 bsp=e0000040f39b1040 > [] release_sock+0x100/0x1c0 > sp=e0000040f39b7c90 bsp=e0000040f39b1010 > [] tcp_sendmsg+0x1a00/0x1ca0 > sp=e0000040f39b7c90 bsp=e0000040f39b0f58 > [] inet_sendmsg+0xd0/0x100 > sp=e0000040f39b7ca0 bsp=e0000040f39b0f20 > [] sock_aio_write+0x280/0x2e0 > sp=e0000040f39b7ca0 bsp=e0000040f39b0ed0 > [] do_sync_write+0x180/0x200 > sp=e0000040f39b7d20 bsp=e0000040f39b0e98 > [] vfs_write+0x230/0x3a0 > sp=e0000040f39b7e20 bsp=e0000040f39b0e48 > [] sys_write+0x70/0xe0 > sp=e0000040f39b7e20 bsp=e0000040f39b0dc8 > [] ia64_trace_syscall+0xd0/0x110 > sp=e0000040f39b7e30 bsp=e0000040f39b0dc8 > [] __kernel_syscall_via_break+0x0/0x20 > sp=e0000040f39b8000 bsp=e0000040f39b0dc8 > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > From jwilson at redhat.com Tue Aug 14 14:23:12 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 10:23:12 -0400 Subject: Anyone else? In-Reply-To: <46C1BA51.10009@redhat.com> References: <46C1BA51.10009@redhat.com> Message-ID: <46C1BAD0.7060303@redhat.com> Prarit Bhargava wrote: > Is anyone else seeing this when scp'ing INTO a box with F8T1 or newer > kernels? x86_64, intel 4-way .... > > > BUG: warning at kernel/softirq.c:138/local_bh > _enable() (Not tainted) I haven't seen it myself, but I know I've seen this message in a few bugzilla subjects now... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From prarit at redhat.com Tue Aug 14 14:24:37 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Tue, 14 Aug 2007 10:24:37 -0400 Subject: Anyone else? In-Reply-To: <46C1BAD0.7060303@redhat.com> References: <46C1BA51.10009@redhat.com> <46C1BAD0.7060303@redhat.com> Message-ID: <46C1BB25.7000506@redhat.com> Jarod Wilson wrote: > Prarit Bhargava wrote: > >> Is anyone else seeing this when scp'ing INTO a box with F8T1 or newer >> kernels? x86_64, intel 4-way .... >> >> >> BUG: warning at kernel/softirq.c:138/local_bh >> _enable() (Not tainted) >> > > I haven't seen it myself, but I know I've seen this message in a few > bugzilla subjects now... > > The BUG warning is generic -- so it could be a large # of issues causing the same message :/ P. From jwilson at redhat.com Tue Aug 14 18:32:53 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 14:32:53 -0400 Subject: modsign vs build-id In-Reply-To: <20070814061629.1F9794D057D@magilla.localdomain> References: <20070814061629.1F9794D057D@magilla.localdomain> Message-ID: <46C1F555.5080403@redhat.com> Roland McGrath wrote: > I fixed this in rawhide kernel.spec over the weekend and left a somewhat > detailed comment in the changed bit. But I thought I'd bring this up > directly and explain the story. > > The short version of What Broke is "what, you sha1 on me? no, i sha1 on you!" Something I'm still seeing: $ rpmbuild --bb --with baseonly --without debuginfo kernel.spec [...] Processing files: kernel-headers-2.6.23-0.104.rc3.vsc.fc8 Provides: glibc-kernheaders = 3.0-46 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 Obsoletes: glibc-kernheaders Processing files: kernel-devel-2.6.23-0.104.rc3.vsc.fc8 warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64 warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64/.config [...repeat for every file in kernel-devel...] warning: File listed twice: /usr/src/kernels/2.6.23-0.104.rc3.vsc.fc8-x86_64/usr/Makefile Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/kernel-2.6.23-0.104.rc3.vsc.fc8-root-x86_64 Wrote: /usr/src/redhat/RPMS/x86_64/kernel-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Wrote: /usr/src/redhat/RPMS/x86_64/kernel-headers-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Wrote: /usr/src/redhat/RPMS/x86_64/kernel-devel-2.6.23-0.104.rc3.vsc.fc8.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.34783 + umask 022 + cd /usr/src/redhat/BUILD + cd kernel-2.6.22 + rm -rf /var/tmp/kernel-2.6.23-0.104.rc3.vsc.fc8-root-x86_64 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.42722 + umask 022 + cd /usr/src/redhat/BUILD + rm -rf kernel-2.6.22 + exit 0 -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 18:39:12 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 11:39:12 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 14:32:53 -0400 <46C1F555.5080403@redhat.com> Message-ID: <20070814183912.56E114D0571@magilla.localdomain> This has nothing to do with the modsign issue. From jwilson at redhat.com Tue Aug 14 18:50:53 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 14:50:53 -0400 Subject: modsign vs build-id In-Reply-To: <20070814183912.56E114D0571@magilla.localdomain> References: <20070814183912.56E114D0571@magilla.localdomain> Message-ID: <46C1F98D.6070609@redhat.com> Roland McGrath wrote: > This has nothing to do with the modsign issue. Hrm... It didn't start happening (that I noticed) until after some of the recent changes you'd made, so I thought you might have an inkling as to what was going on. However, the behavior of the resulting kernel build *does* appear to be related. I can't load any modules: # modprobe e1000 FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was rejected by service. Best guess is that something goes haywire since I did this build '--without debuginfo'. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 19:02:35 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 12:02:35 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 14:50:53 -0400 <46C1F98D.6070609@redhat.com> Message-ID: <20070814190235.B10D04D0571@magilla.localdomain> > Roland McGrath wrote: > > This has nothing to do with the modsign issue. > > Hrm... It didn't start happening (that I noticed) until after some of > the recent changes you'd made, so I thought you might have an inkling as > to what was going on. I do, but it's harmless and not related to the modsign issue. > However, the behavior of the resulting kernel build *does* appear to be > related. I can't load any modules: > > # modprobe e1000 > FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was > rejected by service. The is the failure mode that revision 1.84 of kernel.spec fixed. Are you using the current spec? > Best guess is that something goes haywire since I did this build > '--without debuginfo'. I can't see how that would break the fix for module signing. Thanks, Roland From jwilson at redhat.com Tue Aug 14 19:09:44 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 15:09:44 -0400 Subject: modsign vs build-id In-Reply-To: <20070814190235.B10D04D0571@magilla.localdomain> References: <20070814190235.B10D04D0571@magilla.localdomain> Message-ID: <46C1FDF8.6070000@redhat.com> >> Roland McGrath wrote: >>> This has nothing to do with the modsign issue. >> Hrm... It didn't start happening (that I noticed) until after some of >> the recent changes you'd made, so I thought you might have an inkling = as >> to what was going on. >=20 > I do, but it's harmless and not related to the modsign issue. My main point was to make sure it was going to get fixed, and if you already know what's up, I presume you'll fix it and I don't need to spend time looking into it. :) >> However, the behavior of the resulting kernel build *does* appear to b= e >> related. I can't load any modules: >> >> # modprobe e1000 >> FATAL: Error inserting e1000 (/lib/modules/.../e1000.ko): Key was >> rejected by service. >=20 > The is the failure mode that revision 1.84 of kernel.spec fixed. > Are you using the current spec? That was from revision 1.87. >> Best guess is that something goes haywire since I did this build >> '--without debuginfo'. >=20 > I can't see how that would break the fix for module signing. Was just a guess and perhaps not even an educated one. I'll poke at it a bit more. --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 19:16:20 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 12:16:20 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 15:09:44 -0400 <46C1FDF8.6070000@redhat.com> Message-ID: <20070814191620.DD1354D0571@magilla.localdomain> > That was from revision 1.87. Hmm. Actually the failure mode from before was not "modprobe" problems, but never getting that far because the insmods in the initrd failed. Do you have some magical setup that needs no modules? Or did it really succeed at boot-time insmods and then modprobe fails? Thanks, Roland From jwilson at redhat.com Tue Aug 14 19:22:31 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 15:22:31 -0400 Subject: modsign vs build-id In-Reply-To: <20070814191620.DD1354D0571@magilla.localdomain> References: <20070814191620.DD1354D0571@magilla.localdomain> Message-ID: <46C200F7.7070100@redhat.com> Roland McGrath wrote: >> That was from revision 1.87. > > Hmm. Actually the failure mode from before was not "modprobe" problems, > but never getting that far because the insmods in the initrd failed. > Do you have some magical setup that needs no modules? Or did it really > succeed at boot-time insmods and then modprobe fails? Looks like it really succeeded at boot-time insmods, I've got dm_*, ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and {e,o,u}hci_hcd modules all loaded. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 19:26:36 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 12:26:36 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 15:22:31 -0400 <46C200F7.7070100@redhat.com> Message-ID: <20070814192636.D474B4D0571@magilla.localdomain> > Roland McGrath wrote: > >> That was from revision 1.87. > > > > Hmm. Actually the failure mode from before was not "modprobe" problems, > > but never getting that far because the insmods in the initrd failed. > > Do you have some magical setup that needs no modules? Or did it really > > succeed at boot-time insmods and then modprobe fails? > > Looks like it really succeeded at boot-time insmods, I've got dm_*, > ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and > {e,o,u}hci_hcd modules all loaded. Ok, color me ungentlemanly, but I have to ask if you've got the right things installed on disk where modprobe is looking. I mean, where did you get those modules with good signatures for the initrd if the ones on disk are bad? This is encouraging me to add the hack I had in mind the other day to make the kernel tell you the public key it's using in a /sys file. Thanks, Roland From jwilson at redhat.com Tue Aug 14 19:48:16 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 15:48:16 -0400 Subject: modsign vs build-id In-Reply-To: <20070814192636.D474B4D0571@magilla.localdomain> References: <20070814192636.D474B4D0571@magilla.localdomain> Message-ID: <46C20700.5040802@redhat.com> Roland McGrath wrote: >> Roland McGrath wrote: >>>> That was from revision 1.87. >>> Hmm. Actually the failure mode from before was not "modprobe" problems, >>> but never getting that far because the insmods in the initrd failed. >>> Do you have some magical setup that needs no modules? Or did it really >>> succeed at boot-time insmods and then modprobe fails? >> Looks like it really succeeded at boot-time insmods, I've got dm_*, >> ata_piix, ata_generic, libata, sd_mod, scsi_mod, ext3, jbd, mbcache and >> {e,o,u}hci_hcd modules all loaded. > > Ok, color me ungentlemanly, but I have to ask if you've got the right > things installed on disk where modprobe is looking. So far as I know, yeah. I built an rpm and installed it, then booted from the entry the kernel %post added to grub.conf, same as I've always done... :) > I mean, where did you > get those modules with good signatures for the initrd if the ones on disk > are bad? Ya got me, but upon unpacking the initrd, modinfo tells me the bits in the initrd have the right vermagic. However, the file sizes don't match. In fact, they aren't even close. # (cd /tmp/initrd-104/lib; ll ext3.ko) -rw------- 1 root root 189096 2007-08-14 15:31 ext3.ko # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko Okay, so I rebuilt the initrd and bounced the box... And there's the expected kernel panic. So now I'm thoroughly confused as to where the hell the modules that at least booted the system came from... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cebbert at redhat.com Tue Aug 14 19:51:34 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 14 Aug 2007 15:51:34 -0400 Subject: modsign vs build-id In-Reply-To: <46C20700.5040802@redhat.com> References: <20070814192636.D474B4D0571@magilla.localdomain> <46C20700.5040802@redhat.com> Message-ID: <46C207C6.4030100@redhat.com> On 08/14/2007 03:48 PM, Jarod Wilson wrote: > > Ya got me, but upon unpacking the initrd, modinfo tells me the bits in > the initrd have the right vermagic. However, the file sizes don't match. > In fact, they aren't even close. > > # (cd /tmp/initrd-104/lib; ll ext3.ko) > -rw------- 1 root root 189096 2007-08-14 15:31 ext3.ko > > # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) > -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko > Looks like one has the debug info in it and the other doesn't. From roland at redhat.com Tue Aug 14 20:00:19 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 13:00:19 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 15:48:16 -0400 <46C20700.5040802@redhat.com> Message-ID: <20070814200019.C75224D0571@magilla.localdomain> > Ya got me, but upon unpacking the initrd, modinfo tells me the bits in > the initrd have the right vermagic. That doesn't tell you anything useful. Compare the signature sections, e.g. readelf -x .module_sig on each. > However, the file sizes don't match. > In fact, they aren't even close. > > # (cd /tmp/initrd-104/lib; ll ext3.ko) > -rw------- 1 root root 189096 2007-08-14 15:31 ext3.ko > > # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) > -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko mkinitrd runs strip -g on the modules copied to the initrd. I hadn't noticed that before, but it should not be a problem. (Its affect on the signature issue should not have changed.) > Okay, so I rebuilt the initrd and bounced the box... And there's the > expected kernel panic. So now I'm thoroughly confused as to where the > hell the modules that at least booted the system came from... Ok, we'll call the first experience a mysterious hiccup then. Did you save your rpmbuild log? Can you double-check that it has no debugedit or find-debuginfo.sh runs that follow the modsign.sh runs? Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. Thanks, Roland From cebbert at redhat.com Tue Aug 14 20:18:26 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 14 Aug 2007 16:18:26 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed Message-ID: <46C20E12.9010906@redhat.com> Is anyone looking at this? The basic proposal is to create /etc/kernel/preinst.d and /etc/kernel/postinst.d directories and let external packages drop scripts in there that get called on every kernel install. From katzj at redhat.com Tue Aug 14 20:26:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Aug 2007 16:26:14 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <46C20E12.9010906@redhat.com> References: <46C20E12.9010906@redhat.com> Message-ID: <1187123174.22509.31.camel@localhost.localdomain> On Tue, 2007-08-14 at 16:18 -0400, Chuck Ebbert wrote: > Is anyone looking at this? The basic proposal is to create > /etc/kernel/preinst.d and /etc/kernel/postinst.d directories > and let external packages drop scripts in there that get called > on every kernel install. The easiest place for it to not require lots of cruft in the kernel spec file would be /sbin/new-kernel-pkg. I'm not going to pass judgement on it being a good idea or not though :) Jeremy From jwilson at redhat.com Tue Aug 14 20:30:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 16:30:48 -0400 Subject: modsign vs build-id In-Reply-To: <20070814200019.C75224D0571@magilla.localdomain> References: <20070814200019.C75224D0571@magilla.localdomain> Message-ID: <46C210F8.2040300@redhat.com> Roland McGrath wrote: >> Ya got me, but upon unpacking the initrd, modinfo tells me the bits in >> the initrd have the right vermagic. > > That doesn't tell you anything useful. Compare the signature sections, > e.g. readelf -x .module_sig on each. The signature sections are identical. Triple-checked that I was comparing with the ext3.ko from the initrd that booted the system. >> However, the file sizes don't match. >> In fact, they aren't even close. >> >> # (cd /tmp/initrd-104/lib; ll ext3.ko) >> -rw------- 1 root root 189096 2007-08-14 15:31 ext3.ko >> >> # (cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kerne/fs/ext3; ll ext3.ko) >> -rw-r--r-- 1 root root 2719832 2007-08-14 12:46 ext3.ko > > mkinitrd runs strip -g on the modules copied to the initrd. > I hadn't noticed that before, but it should not be a problem. > (Its affect on the signature issue should not have changed.) And indeed, the size matches if I manually run strip -g on the unstripped ko. To make it even more interesting: # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 # insmod e1000.ko Modules signature verification failed insmod: error inserting 'e1000.ko': -1 Key was rejected by service # strip -g e1000.ko # insmod e1000.ko # lsmod |grep e1000 e1000 125977 0 >> Okay, so I rebuilt the initrd and bounced the box... And there's the >> expected kernel panic. Only, if mkinitrd is stripping the modules, based on the above info, this *should* have worked... >> So now I'm thoroughly confused as to where the >> hell the modules that at least booted the system came from... > > Ok, we'll call the first experience a mysterious hiccup then. > > Did you save your rpmbuild log? Can you double-check that it has no > debugedit or find-debuginfo.sh runs that follow the modsign.sh runs? I didn't save it, but I can do a rebuild with the same options. > Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c > (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. Sure, I'll add that too. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 20:41:57 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 13:41:57 -0700 (PDT) Subject: modsign vs build-id In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 16:30:48 -0400 <46C210F8.2040300@redhat.com> Message-ID: <20070814204157.3D70F4D0571@magilla.localdomain> > The signature sections are identical. Triple-checked that I was > comparing with the ext3.ko from the initrd that booted the system. [...] > To make it even more interesting: > > # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 > # insmod e1000.ko > Modules signature verification failed > insmod: error inserting 'e1000.ko': -1 Key was rejected by service > # strip -g e1000.ko > # insmod e1000.ko > # lsmod |grep e1000 > e1000 125977 0 Ok. This makes me think that the signature generation and/or verification are looking at something they shouldn't be. i.e., something strip changed. > > Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c > > (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. > > Sure, I'll add that too. Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract for a given module and the printks from verification looking at that module should give us something to go on. Thanks, Roland From jwilson at redhat.com Tue Aug 14 20:43:07 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 16:43:07 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <1187123174.22509.31.camel@localhost.localdomain> References: <46C20E12.9010906@redhat.com> <1187123174.22509.31.camel@localhost.localdomain> Message-ID: <46C213DB.10702@redhat.com> Jeremy Katz wrote: > On Tue, 2007-08-14 at 16:18 -0400, Chuck Ebbert wrote: >> Is anyone looking at this? Only insofar as asking for yours and davej's thoughts about doing it. >> The basic proposal is to create >> /etc/kernel/preinst.d and /etc/kernel/postinst.d directories >> and let external packages drop scripts in there that get called >> on every kernel install. > > The easiest place for it to not require lots of cruft in the kernel spec > file would be /sbin/new-kernel-pkg. Ooh, I like that. > I'm not going to pass judgement on it being a good idea or not though :) I will! I think it could be a Good Thing or at least a Useful Thing for both kmod packages and dkms payloads. Of course, I also see the potential for abuse here... Sketchy kmods or dkms payloads could potentially wreak havoc on kernel installs if they cause a hang or failure. I'd be happy to take a crack at implementation. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Tue Aug 14 20:45:56 2007 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Aug 2007 13:45:56 -0700 (PDT) Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: Jarod Wilson's message of Tuesday, 14 August 2007 16:43:07 -0400 <46C213DB.10702@redhat.com> Message-ID: <20070814204556.317AF4D0571@magilla.localdomain> Is there a reason to add a hack to the kernel %post in particular, instead of just making people use rpm triggers? I mean, horror and all that. But at least it's generic SEP horror, and not new hair for the kernel rpm itself (i.e. our problem). Thanks, Roland From cebbert at redhat.com Tue Aug 14 21:16:11 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 14 Aug 2007 17:16:11 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <46C213DB.10702@redhat.com> References: <46C20E12.9010906@redhat.com> <1187123174.22509.31.camel@localhost.localdomain> <46C213DB.10702@redhat.com> Message-ID: <46C21B9B.8060404@redhat.com> On 08/14/2007 04:43 PM, Jarod Wilson wrote: > > I will! I think it could be a Good Thing or at least a Useful Thing for > both kmod packages and dkms payloads. Of course, I also see the > potential for abuse here... Sketchy kmods or dkms payloads could > potentially wreak havoc on kernel installs if they cause a hang or failure. > That's what scares me about the whole idea. From jwilson at redhat.com Tue Aug 14 21:25:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 17:25:48 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <20070814204556.317AF4D0571@magilla.localdomain> References: <20070814204556.317AF4D0571@magilla.localdomain> Message-ID: <46C21DDC.9090303@redhat.com> Roland McGrath wrote: > Is there a reason to add a hack to the kernel %post in particular, > instead of just making people use rpm triggers? I mean, horror and all that. > But at least it's generic SEP horror, and not new hair for the kernel rpm > itself (i.e. our problem). On the surface, I don't see why the couldn't. I suppose we should prod Matt Domsch on why he's against using triggers for dkms, since his objection in the bug doesn't list any details... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Tue Aug 14 21:36:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Aug 2007 17:36:35 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <46C21DDC.9090303@redhat.com> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> Message-ID: <1187127395.16252.1.camel@localhost.localdomain> On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote: > Roland McGrath wrote: > > Is there a reason to add a hack to the kernel %post in particular, > > instead of just making people use rpm triggers? I mean, horror and all that. > > But at least it's generic SEP horror, and not new hair for the kernel rpm > > itself (i.e. our problem). > > On the surface, I don't see why the couldn't. I suppose we should prod > Matt Domsch on why he's against using triggers for dkms, since his > objection in the bug doesn't list any details... Triggers run at not exactly the time you expect them to. Which makes them a little bit less helpful. Really, you want to plug-in after depmod, etc are run but before the initrd is made. And you can't do that from a trigger. Also, triggers manage to cause all sorts of crazy fun weird corner cases. Fear them. :-) Jeremy From jwilson at redhat.com Tue Aug 14 21:43:48 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 17:43:48 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <1187127395.16252.1.camel@localhost.localdomain> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> Message-ID: <46C22214.8090404@redhat.com> Jeremy Katz wrote: > On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote: >> Roland McGrath wrote: >>> Is there a reason to add a hack to the kernel %post in particular, >>> instead of just making people use rpm triggers? I mean, horror and all that. >>> But at least it's generic SEP horror, and not new hair for the kernel rpm >>> itself (i.e. our problem). >> On the surface, I don't see why the couldn't. I suppose we should prod >> Matt Domsch on why he's against using triggers for dkms, since his >> objection in the bug doesn't list any details... > > Triggers run at not exactly the time you expect them to. Which makes > them a little bit less helpful. Really, you want to plug-in after > depmod, etc are run but before the initrd is made. And you can't do > that from a trigger. Ew, yeah, okay, I could see that having odd side-effects in a few cases... So what you're saying is we should do this in new-kernel-pkg? ;) At least that would make it mostly mkinitrd's problem and not the kernel's... > Also, triggers manage to cause all sorts of crazy fun weird corner > cases. Fear them. :-) /me cringes in terror... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Tue Aug 14 21:48:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 14 Aug 2007 17:48:21 -0400 Subject: modsign vs build-id In-Reply-To: <20070814204157.3D70F4D0571@magilla.localdomain> References: <20070814204157.3D70F4D0571@magilla.localdomain> Message-ID: <46C22325.4010306@redhat.com> Roland McGrath wrote: >> The signature sections are identical. Triple-checked that I was >> comparing with the ext3.ko from the initrd that booted the system. > [...] >> To make it even more interesting: >> >> # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 >> # insmod e1000.ko >> Modules signature verification failed >> insmod: error inserting 'e1000.ko': -1 Key was rejected by service >> # strip -g e1000.ko >> # insmod e1000.ko >> # lsmod |grep e1000 >> e1000 125977 0 > > Ok. This makes me think that the signature generation and/or verification > are looking at something they shouldn't be. i.e., something strip changed. > >>> Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c >>> (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. >> Sure, I'll add that too. > > Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract > for a given module and the printks from verification looking at that module > should give us something to go on. The build is just about done, but I gotta run. I'll poke at it some more in a few hours though... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Tue Aug 14 23:06:23 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Aug 2007 19:06:23 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <46C22214.8090404@redhat.com> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> Message-ID: <1187132783.3028.1.camel@localhost.localdomain> On Tue, 2007-08-14 at 17:43 -0400, Jarod Wilson wrote: > Jeremy Katz wrote: > > On Tue, 2007-08-14 at 17:25 -0400, Jarod Wilson wrote: > >> Roland McGrath wrote: > >>> Is there a reason to add a hack to the kernel %post in particular, > >>> instead of just making people use rpm triggers? I mean, horror and all that. > >>> But at least it's generic SEP horror, and not new hair for the kernel rpm > >>> itself (i.e. our problem). > >> On the surface, I don't see why the couldn't. I suppose we should prod > >> Matt Domsch on why he's against using triggers for dkms, since his > >> objection in the bug doesn't list any details... > > > > Triggers run at not exactly the time you expect them to. Which makes > > them a little bit less helpful. Really, you want to plug-in after > > depmod, etc are run but before the initrd is made. And you can't do > > that from a trigger. > > Ew, yeah, okay, I could see that having odd side-effects in a few > cases... So what you're saying is we should do this in new-kernel-pkg? > ;) At least that would make it mostly mkinitrd's problem and not the > kernel's... When mdomsch, davej, jcm and I talked about it back in February, that was the conclusion we reached. It should be pretty simple, too -- just pick a directory[1], run things out of it that are executable. Again, leaving out whether or not its a good idea ;-) Jeremy [1] Likely to be the most difficult part From jwboyer at jdub.homelinux.org Wed Aug 15 02:39:08 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 14 Aug 2007 21:39:08 -0500 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <1187132783.3028.1.camel@localhost.localdomain> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> <1187132783.3028.1.camel@localhost.localdomain> Message-ID: <20070814213908.6d80b0ad@Nokia-N800-26> On Tue, 14 Aug 2007 19:06:23 -0400 Jeremy Katz wrote: > > When mdomsch, davej, jcm and I talked about it back in February, that > was the conclusion we reached. It should be pretty simple, too -- > just pick a directory[1], run things out of it that are executable. > > Again, leaving out whether or not its a good idea ;-) I'd rather you comment about that as well. As I understand things, this would make DKMS payloads much easier. There are some looking at replacing kmods with that... josh From jwilson at redhat.com Wed Aug 15 04:02:25 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 15 Aug 2007 00:02:25 -0400 Subject: modsign vs build-id In-Reply-To: <46C22325.4010306@redhat.com> References: <20070814204157.3D70F4D0571@magilla.localdomain> <46C22325.4010306@redhat.com> Message-ID: <46C27AD1.1040205@redhat.com> Jarod Wilson wrote: > Roland McGrath wrote: >>> The signature sections are identical. Triple-checked that I was >>> comparing with the ext3.ko from the initrd that booted the system. >> [...] >>> To make it even more interesting: >>> >>> # cd /lib/modules/2.6.23-0.104.rc3.vsc.fc8/kernel/drivers/net/e1000 >>> # insmod e1000.ko >>> Modules signature verification failed >>> insmod: error inserting 'e1000.ko': -1 Key was rejected by service >>> # strip -g e1000.ko >>> # insmod e1000.ko >>> # lsmod |grep e1000 >>> e1000 125977 0 >> Ok. This makes me think that the signature generation and/or verification >> are looking at something they shouldn't be. i.e., something strip changed. >> >>>> Also, you could try setting MODSIGN_DEBUG in kernel/module-verify-sig.c >>>> (linux-2.6-modsign-core.patch) and booting with "debug" to see those msgs. >>> Sure, I'll add that too. >> Also hack modsign.sh to pass -v to mod-extract. The logs from mod-extract >> for a given module and the printks from verification looking at that module >> should give us something to go on. > > The build is just about done, but I gotta run. I'll poke at it some more > in a few hours though... Hrm, something appears to have gone a touch screwy with my output redirection, but most of the good stuff (from mod-extract -v) is there: http://people.redhat.com/jwilson/misc/buildlog dmesg output (as much as possible) post-boot here: http://people.redhat.com/jwilson/misc/dmesg-modsign -- Jarod Wilson jwilson at redhat.com From fedora at leemhuis.info Wed Aug 15 05:00:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 07:00:57 +0200 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <20070814213908.6d80b0ad@Nokia-N800-26> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> <1187132783.3028.1.camel@localhost.localdomain> <20070814213908.6d80b0ad@Nokia-N800-26> Message-ID: <46C28889.70704@leemhuis.info> On 15.08.2007 04:39, Josh Boyer wrote: > On Tue, 14 Aug 2007 19:06:23 -0400 > Jeremy Katz wrote: >> When mdomsch, davej, jcm and I talked about it back in February, that >> was the conclusion we reached. It should be pretty simple, too -- >> just pick a directory[1], run things out of it that are executable. >> >> Again, leaving out whether or not its a good idea ;-) > > I'd rather you comment about that as well. As I understand things, > this would make DKMS payloads much easier. There are some looking at > replacing kmods with that... Well, I'd really like to see a combination of dkms and kmod's, so ordinary users can get pre-compiled modules as kmods (or another packaging standard for pre-compiled kernel-modules) and other can use dkms if they want (or it could jump in in cases where the pre-compiled packages are not yet available). Just relying on dkms sounds crazy in my eyes. BTW, the real solution for the bug which is mentioned in the subject of this mail would be to dkms put the modules in a rpm that depends on the kernel. Then it would be removed fine on kernel-uninstall. CU knurd From ehabkost at redhat.com Wed Aug 15 12:32:37 2007 From: ehabkost at redhat.com (Eduardo Habkost) Date: Wed, 15 Aug 2007 09:32:37 -0300 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <46C28889.70704@leemhuis.info> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> <1187132783.3028.1.camel@localhost.localdomain> <20070814213908.6d80b0ad@Nokia-N800-26> <46C28889.70704@leemhuis.info> Message-ID: <20070815123236.GD14702@blackpad.ctb.virtua.com.br> On Wed, Aug 15, 2007 at 07:00:57AM +0200, Thorsten Leemhuis wrote: > > Well, I'd really like to see a combination of dkms and kmod's, so > ordinary users can get pre-compiled modules as kmods (or another > packaging standard for pre-compiled kernel-modules) and other can use > dkms if they want (or it could jump in in cases where the pre-compiled > packages are not yet available). > > Just relying on dkms sounds crazy in my eyes. > > BTW, the real solution for the bug which is mentioned in the subject of > this mail would be to dkms put the modules in a rpm that depends on the > kernel. Then it would be removed fine on kernel-uninstall. The modules built by dkms aren't included on a package because they are built on demand on the user machine. Or do you suggest that DKMS generate and install a RPM package when new modules are compiled? -- Eduardo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Aug 15 12:42:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 15 Aug 2007 14:42:11 +0200 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <20070815123236.GD14702@blackpad.ctb.virtua.com.br> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> <1187132783.3028.1.camel@localhost.localdomain> <20070814213908.6d80b0ad@Nokia-N800-26> <46C28889.70704@leemhuis.info> <20070815123236.GD14702@blackpad.ctb.virtua.com.br> Message-ID: <46C2F4A3.7060409@leemhuis.info> On 15.08.2007 14:32, Eduardo Habkost wrote: > On Wed, Aug 15, 2007 at 07:00:57AM +0200, Thorsten Leemhuis wrote: >> Well, I'd really like to see a combination of dkms and kmod's, so >> ordinary users can get pre-compiled modules as kmods (or another >> packaging standard for pre-compiled kernel-modules) and other can use >> dkms if they want (or it could jump in in cases where the pre-compiled >> packages are not yet available). >> >> Just relying on dkms sounds crazy in my eyes. >> >> BTW, the real solution for the bug which is mentioned in the subject of >> this mail would be to dkms put the modules in a rpm that depends on the >> kernel. Then it would be removed fine on kernel-uninstall. > > The modules built by dkms aren't included on a package because they > are built on demand on the user machine. And that's bad ^w^w can be problematic for the same reasons why installing CPAN-Modules or other Software without using rpm. > Or do you suggest that DKMS generate and install a RPM package when new > modules are compiled? The latter, which is possible afaik dkms. BTW, I'm still interested in a kind of "kmod and dkms" merger, do have both functionalities under one hood. But I still can't find a way to make that work with maintaining only *one* spec-file/buildpath. I'd appreciate it if someone could enlighten me if that's possible somehow. CU knurd From katzj at redhat.com Wed Aug 15 14:06:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 15 Aug 2007 10:06:15 -0400 Subject: Bugzilla Bug 250377: External modules of removed kernels are not removed In-Reply-To: <20070814213908.6d80b0ad@Nokia-N800-26> References: <20070814204556.317AF4D0571@magilla.localdomain> <46C21DDC.9090303@redhat.com> <1187127395.16252.1.camel@localhost.localdomain> <46C22214.8090404@redhat.com> <1187132783.3028.1.camel@localhost.localdomain> <20070814213908.6d80b0ad@Nokia-N800-26> Message-ID: <1187186775.26955.0.camel@localhost.localdomain> On Tue, 2007-08-14 at 21:39 -0500, Josh Boyer wrote: > On Tue, 14 Aug 2007 19:06:23 -0400 > Jeremy Katz wrote: > > When mdomsch, davej, jcm and I talked about it back in February, that > > was the conclusion we reached. It should be pretty simple, too -- > > just pick a directory[1], run things out of it that are executable. > > > > Again, leaving out whether or not its a good idea ;-) > > I'd rather you comment about that as well. As I understand things, > this would make DKMS payloads much easier. There are some looking at > replacing kmods with that... Yes, it makes doing things like dkms or even some of the kmodtool horrors easier. And thus I suspect it's something of a necessary evil. Doesn't mean I have to like it, though. Jeremy From mkent at magoazul.com Wed Aug 15 22:57:32 2007 From: mkent at magoazul.com (Matthew Kent) Date: Wed, 15 Aug 2007 15:57:32 -0700 Subject: [PATCH] fix development --with vanilla build Message-ID: <1187218653.6415.11.camel@fuego> Tiny patch to fix vanilla builds trying to make a missing target. -- Matthew Kent http://magoazul.com -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-2.6.23-0.105.rc3.fc8_spec.patch Type: text/x-patch Size: 898 bytes Desc: not available URL: From swhiteho at redhat.com Thu Aug 16 12:21:17 2007 From: swhiteho at redhat.com (Steven Whitehouse) Date: Thu, 16 Aug 2007 13:21:17 +0100 Subject: GFS2/DLM Exports request Message-ID: <1187266877.8765.885.camel@quoit> Hi, Please add the following patch to the Fedora kernel (F-7, FC-6 & devel). This was originally in the FC-6 kernel but seems to have vanished. This patch isn't going to get sent upstream for various reasons but we need it in Fedora so that the GFS kernel stuff will build against the GFS2 lock modules. Steve. ----------------------------------------------------------------------------- --- linux-2.6.17.noarch/fs/gfs2/locking.c~ 2006-08-10 13:33:09.000000000 -0400 +++ linux-2.6.17.noarch/fs/gfs2/locking.c 2006-08-10 13:33:23.000000000 -0400 @@ -188,4 +188,6 @@ void __init gfs2_init_lmh(void) EXPORT_SYMBOL_GPL(gfs2_register_lockproto); EXPORT_SYMBOL_GPL(gfs2_unregister_lockproto); - +EXPORT_SYMBOL_GPL(gfs2_withdraw_lockproto); +EXPORT_SYMBOL_GPL(gfs2_mount_lockproto); +EXPORT_SYMBOL_GPL(gfs2_unmount_lockproto); From jwboyer at jdub.homelinux.org Thu Aug 16 12:43:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 16 Aug 2007 07:43:15 -0500 Subject: GFS2/DLM Exports request In-Reply-To: <1187266877.8765.885.camel@quoit> References: <1187266877.8765.885.camel@quoit> Message-ID: <20070816074315.26eae372@vader.jdub.homelinux.org> On Thu, 16 Aug 2007 13:21:17 +0100 Steven Whitehouse wrote: > Hi, > > Please add the following patch to the Fedora kernel (F-7, FC-6 & > devel). This was originally in the FC-6 kernel but seems to have > vanished. This patch isn't going to get sent upstream for various > reasons but we need it in Fedora so that the GFS kernel stuff will > build against the GFS2 lock modules. What were the reasons upstream didn't like it? josh From swhiteho at redhat.com Thu Aug 16 12:48:23 2007 From: swhiteho at redhat.com (Steven Whitehouse) Date: Thu, 16 Aug 2007 13:48:23 +0100 Subject: GFS2/DLM Exports request In-Reply-To: <20070816074315.26eae372@vader.jdub.homelinux.org> References: <1187266877.8765.885.camel@quoit> <20070816074315.26eae372@vader.jdub.homelinux.org> Message-ID: <1187268503.8765.893.camel@quoit> Hi, On Thu, 2007-08-16 at 07:43 -0500, Josh Boyer wrote: > On Thu, 16 Aug 2007 13:21:17 +0100 > Steven Whitehouse wrote: > > > Hi, > > > > Please add the following patch to the Fedora kernel (F-7, FC-6 & > > devel). This was originally in the FC-6 kernel but seems to have > > vanished. This patch isn't going to get sent upstream for various > > reasons but we need it in Fedora so that the GFS kernel stuff will > > build against the GFS2 lock modules. > > What were the reasons upstream didn't like it? > > josh We didn't send it to them. I don't want to export this generally because eventually we intend to get rid of the lock module interface and use the dlm interface as "the" way to interface lock managers to GFS2. As a result I'd rather not give the impression to the upstream people that this interface is available for general use. In the mean time however, we are maintaining the older GFS kernel package which does make use of it. There is no intention of submitting the original GFS upstream, and thus there will never be any upstream users of these exports. The patch was in FC-6 originally anyway and got dropped at some stage, Steve. From fedora at leemhuis.info Thu Aug 16 13:17:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 15:17:09 +0200 Subject: [Fwd: Testing the Current Upstream Kernel] Message-ID: <46C44E55.4080900@leemhuis.info> Hi, did you guys see this discussion on LKML? Should we build the vanilla kernel (?) by default during our build process and put it in some special repo maybe (or even in the main repo?)? CU knurd (?) -- btw: Jarod, thx for making it easy to build one -------------- next part -------------- An embedded message was scrubbed... From: Jan Blunck Subject: Testing the Current Upstream Kernel Date: Wed, 15 Aug 2007 13:08:51 +0200 Size: 3920 URL: -------------- next part -------------- An embedded message was scrubbed... From: Sam Ravnborg Subject: Re: Testing the Current Upstream Kernel Date: Wed, 15 Aug 2007 13:14:04 +0200 Size: 3013 URL: -------------- next part -------------- An embedded message was scrubbed... From: Jan Blunck Subject: Re: Testing the Current Upstream Kernel Date: Wed, 15 Aug 2007 11:37:10 +0000 (UTC) Size: 3358 URL: -------------- next part -------------- An embedded message was scrubbed... From: Susanne Oberhauser Subject: Re: Testing the Current Upstream Kernel Date: 16 Aug 2007 12:28:34 +0200 Size: 3414 URL: From ivazqueznet at gmail.com Thu Aug 16 14:31:43 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 16 Aug 2007 10:31:43 -0400 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <46C44E55.4080900@leemhuis.info> References: <46C44E55.4080900@leemhuis.info> Message-ID: <1187274703.11280.32.camel@ignacio.lan> On Thu, 2007-08-16 at 15:17 +0200, Thorsten Leemhuis wrote: > did you guys see this discussion on LKML? Should we build the vanilla > kernel (?) by default during our build process and put it in some > special repo maybe (or even in the main repo?)? http://video.google.com/videoplay?docid=1742374580386548257 "...we do readily accept bug reports against the latest Fedora kernel..." --Andrew Morton (0:54:38 in the above video) This is probably in reference to Rawhide though, so it may still be useful for Fedora's stable releases. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Aug 16 16:28:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 18:28:14 +0200 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <1187274703.11280.32.camel@ignacio.lan> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> Message-ID: <46C47B1E.4090305@leemhuis.info> On 16.08.2007 16:31, Ignacio Vazquez-Abrams wrote: > On Thu, 2007-08-16 at 15:17 +0200, Thorsten Leemhuis wrote: >> did you guys see this discussion on LKML? Should we build the vanilla >> kernel (?) by default during our build process and put it in some >> special repo maybe (or even in the main repo?)? > > http://video.google.com/videoplay?docid=1742374580386548257 > > "...we do readily accept bug reports against the latest Fedora ^^ > kernel..." > --Andrew Morton (0:54:38 in the above video) > > This is probably in reference to Rawhide though, Well, I suppose at least some kernel developers might not agree with that/might not feel as part of the "we" and will ask people to test a vanilla kernel. So I'd say having them in some repo/rawhide would be nice. > so it may still be > useful for Fedora's stable releases. Agreed (I not long ago was in the need to the a vanilla kernel and I really wish I could have yum-installed it). Cu thl From davej at redhat.com Thu Aug 16 16:37:02 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 12:37:02 -0400 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <46C47B1E.4090305@leemhuis.info> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> Message-ID: <20070816163702.GB908@redhat.com> On Thu, Aug 16, 2007 at 06:28:14PM +0200, Thorsten Leemhuis wrote: > > > On 16.08.2007 16:31, Ignacio Vazquez-Abrams wrote: > > On Thu, 2007-08-16 at 15:17 +0200, Thorsten Leemhuis wrote: > >> did you guys see this discussion on LKML? Should we build the vanilla > >> kernel (?) by default during our build process and put it in some > >> special repo maybe (or even in the main repo?)? > > > > http://video.google.com/videoplay?docid=1742374580386548257 > > > > "...we do readily accept bug reports against the latest Fedora > ^^ > > kernel..." > > --Andrew Morton (0:54:38 in the above video) > > > > This is probably in reference to Rawhide though, > > Well, I suppose at least some kernel developers might not agree with > that/might not feel as part of the "we" and will ask people to test a > vanilla kernel. So I'd say having them in some repo/rawhide would be nice. The work that Jarod did to get vanilla builds possible was the only real major thing holding us back from doing this, now the only remaining piece of the puzzle is where do kernel-vanilla packages belong? Once we have that figured out, regular builds and pushes are a breeze. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Aug 16 16:59:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 16 Aug 2007 18:59:29 +0200 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <20070816163702.GB908@redhat.com> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> Message-ID: <46C48271.10504@leemhuis.info> On 16.08.2007 18:37, Dave Jones wrote: > On Thu, Aug 16, 2007 at 06:28:14PM +0200, Thorsten Leemhuis wrote: > > On 16.08.2007 16:31, Ignacio Vazquez-Abrams wrote: > > > On Thu, 2007-08-16 at 15:17 +0200, Thorsten Leemhuis wrote: > > >> did you guys see this discussion on LKML? Should we build the vanilla > > >> kernel (?) by default during our build process and put it in some > > >> special repo maybe (or even in the main repo?)? > > > > > > http://video.google.com/videoplay?docid=1742374580386548257 > > > > > > "...we do readily accept bug reports against the latest Fedora > > ^^ > > > kernel..." > > > --Andrew Morton (0:54:38 in the above video) > > > > > > This is probably in reference to Rawhide though, > > > > Well, I suppose at least some kernel developers might not agree with > > that/might not feel as part of the "we" and will ask people to test a > > vanilla kernel. So I'd say having them in some repo/rawhide would be nice. > > The work that Jarod did to get vanilla builds possible was the only > real major thing holding us back from doing this, Fully agreed. > now the only remaining > piece of the puzzle is where do kernel-vanilla packages belong? Yeah, that's what I meant. We mainly have three choices afaics: * a repo on a account on people.redhat.com / people.fedoraproject.org * directly from koji (e.g. build the vanilla kernel, but don't push it to the proper repos) * in the proper repo I'm unsure myself what the best place. I currently tend a bit to put it in the main repos as that's a service I suppose some users will appreciate. We could close all bugs that are reported specifically against kernel-vanilla with a "report upstream, that's why we ship this kernel". But on the other hand: Some bugs might show up in other packages from Fedora when the software is running under the vanilla kernel. Some users then might say "if you ship it you need to support it". Sometimes it might make sense to fix it, but sometimes it might require kernel-chages, which would not work together with the "vanilla" idea. Maybe we should just try on rawhide first and look if many of such bugs show up? > Once we have that figured out, regular builds and pushes are a breeze. Should we move this discussion to fedora-devel instead, so everyone can participate? Cu knurd From davej at redhat.com Thu Aug 16 17:27:01 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 16 Aug 2007 13:27:01 -0400 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <46C48271.10504@leemhuis.info> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> <46C48271.10504@leemhuis.info> Message-ID: <20070816172701.GA11918@redhat.com> On Thu, Aug 16, 2007 at 06:59:29PM +0200, Thorsten Leemhuis wrote: > We mainly have three choices afaics: > > * a repo on a account on people.redhat.com / people.fedoraproject.org forget p.r.c, it has so many issues it's not worth the time to fight it. p.fp.o has a number of advantages over it, and over time, I'll be moving my existing stuff from the former to the latter. > * directly from koji (e.g. build the vanilla kernel, but don't push it > to the proper repos) not thrilled with this idea. > * in the proper repo Hmm. This would be great, but I think we may get some pushback on this one. (Especially as kernel rpms are so big). I'm thinking that a repo on people.fedoraproject.org is probably the best of the bunch. > Maybe we should just try on rawhide first and look if many of such bugs > show up? > > > Once we have that figured out, regular builds and pushes are a breeze. > > Should we move this discussion to fedora-devel instead, so everyone can > participate? I think most of the concerned parties (rel-eng, infrastructure etc) are represented on this list already. but I've no objection. Dave -- http://www.codemonkey.org.uk From jwilson at redhat.com Thu Aug 16 20:41:45 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 16 Aug 2007 16:41:45 -0400 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <20070816172701.GA11918@redhat.com> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> <46C48271.10504@leemhuis.info> <20070816172701.GA11918@redhat.com> Message-ID: <46C4B689.9060601@redhat.com> > On Thu, Aug 16, 2007 at 06:59:29PM +0200, Thorsten Leemhuis wrote: >=20 > > * in the proper repo >=20 > Hmm. This would be great, but I think we may get some pushback on this > one. (Especially as kernel rpms are so big). >=20 > I'm thinking that a repo on people.fedoraproject.org is probably > the best of the bunch. I kinda like 'in the proper repo' myself, but I'd have to agree a separate repo is probably best. > > Maybe we should just try on rawhide first and look if many of such b= ugs > > show up? > >=20 > > > Once we have that figured out, regular builds and pushes are a bre= eze. > >=20 > > Should we move this discussion to fedora-devel instead, so everyone = can > > participate? > =20 > I think most of the concerned parties (rel-eng, infrastructure etc) are= > represented on this list already. but I've no objection. Note that we can't currently build kernel and kernel-vanilla in the same rpmbuild pass. Further changes to the spec would be needed to make that doable, but if they aren't going in the official repo, perhaps we don't want to do that anyway. --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Thu Aug 16 21:31:19 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 16 Aug 2007 14:31:19 -0700 (PDT) Subject: [PATCH] fix development --with vanilla build In-Reply-To: Matthew Kent's message of Wednesday, 15 August 2007 15:57:32 -0700 <1187218653.6415.11.camel@fuego> Message-ID: <20070816213119.A80624D0461@magilla.localdomain> I committed a slightly different fix for this. Note it should be quite temporary as the relevant patches are on the queue upstream. From fedora at leemhuis.info Fri Aug 17 04:52:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Aug 2007 06:52:29 +0200 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <46C4B689.9060601@redhat.com> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> <46C48271.10504@leemhuis.info> <20070816172701.GA11918@redhat.com> <46C4B689.9060601@redhat.com> Message-ID: <46C5298D.5000308@leemhuis.info> On 16.08.2007 22:41, Jarod Wilson wrote: > [...] > Note that we can't currently build kernel and kernel-vanilla in the same > rpmbuild pass. Further changes to the spec would be needed to make that > doable, [...] Just wondering: Would that be much work or more something like ~15 minutes of work? CU thl From fedora at leemhuis.info Fri Aug 17 05:05:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Aug 2007 07:05:35 +0200 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <20070816172701.GA11918@redhat.com> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> <46C48271.10504@leemhuis.info> <20070816172701.GA11918@redhat.com> Message-ID: <46C52C9F.50402@leemhuis.info> On 16.08.2007 19:27, Dave Jones wrote: > On Thu, Aug 16, 2007 at 06:59:29PM +0200, Thorsten Leemhuis wrote: > > * in the proper repo > Hmm. This would be great, but I think we may get some pushback on this > one. (Especially as kernel rpms are so big). Just wondering: What's "big" here round about? We are talking about round about 20 - 21 MByte per kernel (kernel + devel) afaics; would we ship all flavors (PAE) as vanilla? Maybe most, but not all (xen for example). /me does some math: ix86: default, PAE x86_64: default ppc: default, SMP, kdump Makes 6 kernels, e.g. 120 MByte. If someone puts up a new game for review that needs a 120 MByte data-package would we send him away? No we wouldn't. So why not ship the vanilla kernel in the proper repos? Ohh, sorry, I forgot the debuginfo packages. Ouch, they are 200 MByte in size. Well, that becomes a problem, but: > I'm thinking that a repo on people.fedoraproject.org is probably > the best of the bunch. Which has a 150**MByte Quota iirc -- so you can't ship the debuginfo stuff there either. And non of the other Kernels that you ship via your p.r.c stuff (well, as long as you don't get more space offered, which I assume might be possible). > > [...] > > Should we move this discussion to fedora-devel instead, so everyone can > > participate? > I think most of the concerned parties (rel-eng, infrastructure etc) are > represented on this list already. but I've no objection. If they don't speak up here sooner or later I'll start a thread in fedora-devel ;-) CU knurd From roland at redhat.com Fri Aug 17 05:50:04 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 16 Aug 2007 22:50:04 -0700 (PDT) Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: Thorsten Leemhuis's message of Friday, 17 August 2007 06:52:29 +0200 <46C5298D.5000308@leemhuis.info> Message-ID: <20070817055004.949114D04B7@magilla.localdomain> > On 16.08.2007 22:41, Jarod Wilson wrote: > > [...] > > Note that we can't currently build kernel and kernel-vanilla in the same > > rpmbuild pass. Further changes to the spec would be needed to make that > > doable, [...] > > Just wondering: Would that be much work or more something like ~15 > minutes of work? It's fundamentally unlike the things that are now done in one rpm build. i.e., it is not the same source. From davej at redhat.com Fri Aug 17 11:20:08 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 07:20:08 -0400 Subject: [Fwd: Testing the Current Upstream Kernel] In-Reply-To: <46C52C9F.50402@leemhuis.info> References: <46C44E55.4080900@leemhuis.info> <1187274703.11280.32.camel@ignacio.lan> <46C47B1E.4090305@leemhuis.info> <20070816163702.GB908@redhat.com> <46C48271.10504@leemhuis.info> <20070816172701.GA11918@redhat.com> <46C52C9F.50402@leemhuis.info> Message-ID: <20070817112008.GA1030@redhat.com> On Fri, Aug 17, 2007 at 07:05:35AM +0200, Thorsten Leemhuis wrote: > On 16.08.2007 19:27, Dave Jones wrote: > > On Thu, Aug 16, 2007 at 06:59:29PM +0200, Thorsten Leemhuis wrote: > > > * in the proper repo > > Hmm. This would be great, but I think we may get some pushback on this > > one. (Especially as kernel rpms are so big). > > Just wondering: What's "big" here round about? We are talking about > round about 20 - 21 MByte per kernel (kernel + devel) afaics; would we > ship all flavors (PAE) as vanilla? Maybe most, but not all (xen for > example). No xen, correct. > Ohh, sorry, I forgot the debuginfo packages. Ouch, they are 200 MByte in > size. Well, that becomes a problem Yeah, that's the elephant in the room. > > I'm thinking that a repo on people.fedoraproject.org is probably > > the best of the bunch. > > Which has a 150**MByte Quota iirc -- so you can't ship the debuginfo > stuff there either. And non of the other Kernels that you ship via your > p.r.c stuff (well, as long as you don't get more space offered, which I > assume might be possible). p.r.c doesn't have a huge quota either. (Which is why the repos I have there now don't have debuginfo either). Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Fri Aug 17 16:05:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 17 Aug 2007 12:05:10 -0400 Subject: sparc64 needs an entirely untouched, unstripped kernel Message-ID: <1187366710.3439.192.camel@dhcp83-165.boston.redhat.com> In testing, I've found that sparc64 needs an entirely untouched, unstripped kernel in order to netboot. The kernels which have gone through the debuginfo process did not netboot properly, but an untouched copy of the kernel made right after it is built work fine. This is a variant of the spec code we've been using in Aurora for a while, it enables a with-unstripped option, and only enables it for sparc64. If enabled, it makes a copy, calls it foo-UNSTRIPPED, and includes it in the %files macro. If this is ok, let me know, and I'll commit it in rawhide. If there is a better way to be doing this, also let me know. :) ~spot -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel-unstripped.patch Type: text/x-patch Size: 1664 bytes Desc: not available URL: From davej at redhat.com Fri Aug 17 17:03:02 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 17 Aug 2007 13:03:02 -0400 Subject: sparc64 needs an entirely untouched, unstripped kernel In-Reply-To: <1187366710.3439.192.camel@dhcp83-165.boston.redhat.com> References: <1187366710.3439.192.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070817170302.GC22854@redhat.com> On Fri, Aug 17, 2007 at 12:05:10PM -0400, Tom spot Callaway wrote: > In testing, I've found that sparc64 needs an entirely untouched, > unstripped kernel in order to netboot. The kernels which have gone > through the debuginfo process did not netboot properly, but an untouched > copy of the kernel made right after it is built work fine. > > This is a variant of the spec code we've been using in Aurora for a > while, it enables a with-unstripped option, and only enables it for > sparc64. If enabled, it makes a copy, calls it foo-UNSTRIPPED, and > includes it in the %files macro. > > If this is ok, let me know, and I'll commit it in rawhide. If there is a > better way to be doing this, also let me know. :) Is there a pointer to a spec/standard or something that sparc netbooting uses (or is it just regular PXE?) that might mention caveats that explain why the stripped kernel doesn't netboot? Dave -- http://www.codemonkey.org.uk From tcallawa at redhat.com Fri Aug 17 17:17:00 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 17 Aug 2007 13:17:00 -0400 Subject: sparc64 needs an entirely untouched, unstripped kernel In-Reply-To: <20070817170302.GC22854@redhat.com> References: <1187366710.3439.192.camel@dhcp83-165.boston.redhat.com> <20070817170302.GC22854@redhat.com> Message-ID: <1187371020.3439.195.camel@dhcp83-165.boston.redhat.com> On Fri, 2007-08-17 at 13:03 -0400, Dave Jones wrote: > On Fri, Aug 17, 2007 at 12:05:10PM -0400, Tom spot Callaway wrote: > > In testing, I've found that sparc64 needs an entirely untouched, > > unstripped kernel in order to netboot. The kernels which have gone > > through the debuginfo process did not netboot properly, but an untouched > > copy of the kernel made right after it is built work fine. > > > > This is a variant of the spec code we've been using in Aurora for a > > while, it enables a with-unstripped option, and only enables it for > > sparc64. If enabled, it makes a copy, calls it foo-UNSTRIPPED, and > > includes it in the %files macro. > > > > If this is ok, let me know, and I'll commit it in rawhide. If there is a > > better way to be doing this, also let me know. :) > > Is there a pointer to a spec/standard or something that sparc netbooting > uses (or is it just regular PXE?) that might mention caveats that > explain why the stripped kernel doesn't netboot? Its not regular PXE. We convert the elf kernel to an a.out file, then netboot it via TFTP. ~spot From roland at redhat.com Fri Aug 17 19:29:59 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 17 Aug 2007 12:29:59 -0700 (PDT) Subject: sparc64 needs an entirely untouched, unstripped kernel In-Reply-To: "Tom \"spot\" Callaway"'s message of Friday, 17 August 2007 12:05:10 -0400 <1187366710.3439.192.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070817192959.26A9D4D05B2@magilla.localdomain> I'd like to help figure out what the specific problem is, so we can solve it properly. From tcallawa at redhat.com Fri Aug 17 20:23:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 17 Aug 2007 16:23:34 -0400 Subject: sparc64 needs an entirely untouched, unstripped kernel In-Reply-To: <20070817192959.26A9D4D05B2@magilla.localdomain> References: <20070817192959.26A9D4D05B2@magilla.localdomain> Message-ID: <1187382214.3439.205.camel@dhcp83-165.boston.redhat.com> On Fri, 2007-08-17 at 12:29 -0700, Roland McGrath wrote: > I'd like to help figure out what the specific problem is, so we can solve > it properly. OK, but how do we start? :) ~spot From roland at redhat.com Sat Aug 18 01:17:48 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 17 Aug 2007 18:17:48 -0700 (PDT) Subject: sparc64 needs an entirely untouched, unstripped kernel In-Reply-To: "Tom \"spot\" Callaway"'s message of Friday, 17 August 2007 16:23:34 -0400 <1187382214.3439.205.camel@dhcp83-165.boston.redhat.com> Message-ID: <20070818011748.4A6F24D05B2@magilla.localdomain> > On Fri, 2007-08-17 at 12:29 -0700, Roland McGrath wrote: > > I'd like to help figure out what the specific problem is, so we can solve > > it properly. > > OK, but how do we start? :) I've CC'd Jakub, who has a tendency to know every corner of this sort of thing. If that alone doesn't do it (;-), next we start with asking about exactly how this vmlinux->bootable conversion is done. (Last time I personally dealt with tftp-booting a Sun, it was a Sun 3/60, but it sounds like maybe things haven't changed much. I guess they have a little, since you're tftp'ing a kernel instead of a stage2 boot loader that does bootparam and nfs.) I looked at arch/sparc64/boot/Makefile, but a) don't know where to find elftoaout and b) you were talking about doing something with the image installed in /boot, which is AFAICT not the a.out format image at all. The "image" target in arch/sparc64/boot/Makefile is a mostly-stripped vmlinux (i.e. ELF). What is it that converts that into an a.out image, and where does that image get stored for booting? I surmise that whatever that procedure is depends on a few ELF symbols (-K sun4u_init -K _end -K _start). I'd like to grok all that more fully before suggesting the best solution. Thanks, Roland From cebbert at redhat.com Tue Aug 21 14:29:53 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 21 Aug 2007 10:29:53 -0400 Subject: The NFS "nosharecache" patch in F7 is broken Message-ID: <46CAF6E1.1030702@redhat.com> If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch? From davej at redhat.com Tue Aug 21 15:51:49 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Aug 2007 11:51:49 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CAF6E1.1030702@redhat.com> References: <46CAF6E1.1030702@redhat.com> Message-ID: <20070821155149.GA30242@redhat.com> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: > If people try mounting several exports from the same filesystem, it fails > with confusing error messages if the mount options are different for some > of the mount points. Adding "nosharecache" to the mount options fixes that, > but people with working setups suddenly find they need this new option to > use a setup that used to work without it. Should we just revert that patch? Adding steved to cc (I don't think he's on the list). Dave -- http://www.codemonkey.org.uk From SteveD at redhat.com Tue Aug 21 16:14:27 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 21 Aug 2007 12:14:27 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <20070821155149.GA30242@redhat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> Message-ID: <46CB0F63.7050609@RedHat.com> Dave Jones wrote: > On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: > > If people try mounting several exports from the same filesystem, it fails > > with confusing error messages if the mount options are different for some > > of the mount points. Adding "nosharecache" to the mount options fixes that, > > but people with working setups suddenly find they need this new option to > > use a setup that used to work without it. Should we just revert that patch? Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do.... But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on... steved. From cebbert at redhat.com Tue Aug 21 16:22:00 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Tue, 21 Aug 2007 12:22:00 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CB0F63.7050609@RedHat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CB0F63.7050609@RedHat.com> Message-ID: <46CB1128.4090706@redhat.com> On 08/21/2007 12:14 PM, Steve Dickson wrote: > > > Dave Jones wrote: >> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >> > If people try mounting several exports from the same filesystem, it >> fails >> > with confusing error messages if the mount options are different >> for some >> > of the mount points. Adding "nosharecache" to the mount options >> fixes that, >> > but people with working setups suddenly find they need this new >> option to >> > use a setup that used to work without it. Should we just revert >> that patch? > Thats been the million dollar question lately... there has been quite a > bit of complaints about this patch... but note the check does do some > correct sanity checking so the changes it point would be a good > thing to do.... > > But with that said, I would if making it a warning first, giving > people time to clean up their setups and then making it an > error later on... > Can't it be made to automatically set the nosharecache flag if it's needed? From SteveD at redhat.com Tue Aug 21 16:26:25 2007 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 21 Aug 2007 12:26:25 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CB1128.4090706@redhat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CB0F63.7050609@RedHat.com> <46CB1128.4090706@redhat.com> Message-ID: <46CB1231.5090404@RedHat.com> Chuck Ebbert wrote: > On 08/21/2007 12:14 PM, Steve Dickson wrote: >> >> Dave Jones wrote: >>> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >>> > If people try mounting several exports from the same filesystem, it >>> fails >>> > with confusing error messages if the mount options are different >>> for some >>> > of the mount points. Adding "nosharecache" to the mount options >>> fixes that, >>> > but people with working setups suddenly find they need this new >>> option to >>> > use a setup that used to work without it. Should we just revert >>> that patch? >> Thats been the million dollar question lately... there has been quite a >> bit of complaints about this patch... but note the check does do some >> correct sanity checking so the changes it point would be a good >> thing to do.... >> >> But with that said, I would if making it a warning first, giving >> people time to clean up their setups and then making it an >> error later on... >> > > Can't it be made to automatically set the nosharecache flag if it's needed? thats is an idea that has been kicked around but it turns out it becomes very messy very quickly... steved. From SteveD at redhat.com Wed Aug 22 15:18:21 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 22 Aug 2007 11:18:21 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <20070821155149.GA30242@redhat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> Message-ID: <46CC53BD.5090904@RedHat.com> Dave Jones wrote: > On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: > > If people try mounting several exports from the same filesystem, it fails > > with confusing error messages if the mount options are different for some > > of the mount points. Adding "nosharecache" to the mount options fixes that, > > but people with working setups suddenly find they need this new option to > > use a setup that used to work without it. Should we just revert that patch? Just curious... What are the differences in the mounts options that is causing this new check to pop, which in turn is failing the mount? steved. From cebbert at redhat.com Wed Aug 22 15:24:22 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 22 Aug 2007 11:24:22 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CC53BD.5090904@RedHat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CC53BD.5090904@RedHat.com> Message-ID: <46CC5526.9000309@redhat.com> On 08/22/2007 11:18 AM, Steve Dickson wrote: > > > Dave Jones wrote: >> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >> > If people try mounting several exports from the same filesystem, it >> fails >> > with confusing error messages if the mount options are different >> for some >> > of the mount points. Adding "nosharecache" to the mount options >> fixes that, >> > but people with working setups suddenly find they need this new >> option to >> > use a setup that used to work without it. Should we just revert >> that patch? > Just curious... What are the differences in the mounts options that > is causing this new check to pop, which in turn is failing the mount? In at least one case it is read-only vs. read-write. User mounts something from the server read-only, then mounts selected exports from the same filesystem read-write on top of that. From SteveD at redhat.com Wed Aug 22 15:36:57 2007 From: SteveD at redhat.com (Steve Dickson) Date: Wed, 22 Aug 2007 11:36:57 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CC5526.9000309@redhat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CC53BD.5090904@RedHat.com> <46CC5526.9000309@redhat.com> Message-ID: <46CC5819.7010809@RedHat.com> Chuck Ebbert wrote: > On 08/22/2007 11:18 AM, Steve Dickson wrote: >> >> Dave Jones wrote: >>> On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: >>> > If people try mounting several exports from the same filesystem, it >>> fails >>> > with confusing error messages if the mount options are different >>> for some >>> > of the mount points. Adding "nosharecache" to the mount options >>> fixes that, >>> > but people with working setups suddenly find they need this new >>> option to >>> > use a setup that used to work without it. Should we just revert >>> that patch? >> Just curious... What are the differences in the mounts options that >> is causing this new check to pop, which in turn is failing the mount? > > In at least one case it is read-only vs. read-write. This should not make the check pop... > User mounts something from the server read-only, then mounts selected > exports from the same filesystem read-write on top of that. The check looks for difference protocols, I/O sizes, or cache timeouts so there has to be something other ro/rw that is causing the mounts to fail... steved. From cebbert at redhat.com Wed Aug 22 16:07:38 2007 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 22 Aug 2007 12:07:38 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CC5819.7010809@RedHat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CC53BD.5090904@RedHat.com> <46CC5526.9000309@redhat.com> <46CC5819.7010809@RedHat.com> Message-ID: <46CC5F4A.2030705@redhat.com> On 08/22/2007 11:36 AM, Steve Dickson wrote: >>> Just curious... What are the differences in the mounts options that >>> is causing this new check to pop, which in turn is failing the mount? >> >> In at least one case it is read-only vs. read-write. > This should not make the check pop... > >> User mounts something from the server read-only, then mounts selected >> exports from the same filesystem read-write on top of that. > The check looks for difference protocols, I/O sizes, or cache timeouts > so there has to be something other ro/rw that is causing the > mounts to fail... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253530 This may be some other problem, user changed to r/w and the problem went away: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250271 From feng.xian at gmail.com Thu Aug 23 03:40:20 2007 From: feng.xian at gmail.com (Feng Xian) Date: Wed, 22 Aug 2007 22:40:20 -0500 Subject: how to debug my kernel Message-ID: <610b3d450708222040u3ef3cbddi6c3dd70dd7561157@mail.gmail.com> Hi, I'm currently working on a project which needs to modify linux scheduler. But my new kernel always gets crashed after one-day's run. There is no OOPS message coming out when it crashed. What should I do? Best regards Feng -- Addr: 1025N, 23rd str, APT 33, Lincoln, NE, 68503 Phone: (402)310-9826 WWW: cse.unl.edu/~fxian -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Aug 23 03:44:26 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 22 Aug 2007 23:44:26 -0400 Subject: how to debug my kernel In-Reply-To: <610b3d450708222040u3ef3cbddi6c3dd70dd7561157@mail.gmail.com> References: <610b3d450708222040u3ef3cbddi6c3dd70dd7561157@mail.gmail.com> Message-ID: <20070823034426.GB8120@redhat.com> On Wed, Aug 22, 2007 at 10:40:20PM -0500, Feng Xian wrote: > Hi, > > I'm currently working on a project which needs to modify linux scheduler. > But my new kernel always gets crashed after one-day's run. There is no OOPS > message coming out when it crashed. > What should I do? Post a pointer to your code to Linux kernel and ask there? Seriously, how do you hope us to guess what's wrong with no information at all ? Dave -- http://www.codemonkey.org.uk From steve.shuo.feng at gmail.com Thu Aug 23 04:01:57 2007 From: steve.shuo.feng at gmail.com (=?GB2312?B?t+vLtg==?=) Date: Thu, 23 Aug 2007 12:01:57 +0800 Subject: how to debug my kernel In-Reply-To: <610b3d450708222040u3ef3cbddi6c3dd70dd7561157@mail.gmail.com> References: <610b3d450708222040u3ef3cbddi6c3dd70dd7561157@mail.gmail.com> Message-ID: <88c6482d0708222101x23c0a585nde061ff3b087d146@mail.gmail.com> The most simple solution may be to use serial console :-). You need a dummy (with cross TX/RX) serial cable connecting the box with your modified kernel as the 'debug end' and another Windows/Linux box as 'console'. Boot your kernel with parameter "console=ttyS0,115200" (or any speed your console support), and set your console properly ("remote terminal" on Windows or minicom on Linux), then you can see the kernel output on your console. Set the screen buffer of your console as big as you wish. :-) 2007/8/23, Feng Xian : > > Hi, > > I'm currently working on a project which needs to modify linux scheduler. > But my new kernel always gets crashed after one-day's run. There is no OOPS > message coming out when it crashed. > What should I do? > > Best regards > Feng > > -- > Addr: 1025N, 23rd str, APT 33, > Lincoln, NE, 68503 > Phone: (402)310-9826 > WWW: cse.unl.edu/~fxian > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > > -- Feng Shuo Tel: (86)10-6260-0547 Fax: (86)10-6265-7255 Mailing: P. O. Box 2704# Beijing Postcode: 100080 National Research Centre for High Performance Computers Institute of Computing Technology, Chinese Academy of Sciences No. 6, South Kexueyuan Road, Haidian District Beijing, China -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeen at redhat.com Thu Aug 23 21:20:41 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 23 Aug 2007 16:20:41 -0500 Subject: gcc in f8/x86 using more stack than in rhel5? Message-ID: <46CDFA29.9010801@redhat.com> I did a quick experiment, and it seems that by and large, gcc in f8 (gcc version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) There are a few functions using less, too, though. After much checkstack output frobbing: function [module] : old : new : delta -------------------------------------- acpi_add_single_object [vmlinux]: 156 160 : 4 acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4 adi_connect [adi]: 144 148 : 4 aes_decrypt [aes]: 140 144 : 4 ahc_pci_config [aic7xxx]: 152 148 : -4 ata_do_eh [libata]: 292 304 : 12 aty128_probe [aty128fb]: 272 276 : 4 balance_internal [reiserfs]: 148 160 : 12 bond_arp_send_all [bonding]: 132 136 : 4 capidtmf_recv_block [divacapi]: 188 192 : 4 cciss_update_non_disk_devices [cciss]: 548 552 : 4 cfb_copyarea [vmlinux]: 148 144 : -4 check_balance [reiserfs]: 268 272 : 4 copy_to_user_tmpl [vmlinux]: 400 404 : 4 ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4 decode_rs16 [reed_solomon]: 220 224 : 4 diNewExt [jfs]: 112 108 : -4 diva_add_card [divacapi]: 144 156 : 12 do_balance [reiserfs]: 308 320 : 12 do_cciss_request [cciss]: 544 548 : 4 do_con_write [vmlinux]: 160 156 : -4 do_tx [eni]: 120 124 : 4 ea_dealloc_unstuffed [gfs2]: 116 120 : 4 ehci_urb_enqueue [ehci-hcd]: 196 212 : 16 ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4 ext4_ext_insert_extent [ext4dev]: 144 148 : 4 ext4_ext_remove_space [ext4dev]: 120 124 : 4 facility_req [divacapi]: 396 392 : -4 __fat_readdir [fat]: 252 256 : 4 fat_search_long [fat]: 408 412 : 4 fetch_frame [cpia]: 184 196 : 12 ftdi_elan_status_work [ftdi-elan]: 252 248 : -4 gdth_detect [gdth]: 440 436 : -4 get_far_parent [reiserfs]: 140 152 : 12 hfcpci_interrupt [hisax]: 356 360 : 4 hptiop_probe [hptiop]: 152 156 : 4 huft_build [vmlinux]: 152 144 : -8 ieee80211_master_start_xmit [mac80211]: 176 180 : 4 ieee80211_sta_work [mac80211]: 464 476 : 12 i_ipmi_request [ipmi_msghandler]: 108 100 : -8 inftl_scan_bbt [diskonchip]: 196 200 : 4 ip_route_input [vmlinux]: 196 192 : -4 ip_setsockopt [vmlinux]: 448 452 : 4 isdn_tty_write [isdn]: 160 164 : 4 ivtv_process_vbi_data [ivtv]: 116 120 : 4 jfs_readdir [jfs]: 348 340 : -8 key_schedule [cast5]: 608 596 : -12 matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4 matroxfb_ioctl [matroxfb_base]: 136 140 : 4 mmc_blk_issue_rq [mmc_block]: 360 356 : -4 module_verify_signature [vmlinux]: 124 120 : -4 myri10ge_xmit [myri10ge]: 112 116 : 4 nv_tx_timeout [forcedeth]: 156 144 : -12 ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4 os_scsi_tape_open [osst]: 180 184 : 4 paging32_page_fault [kvm]: 116 108 : -8 parse_audio_unit [snd-usb-audio]: 132 144 : 12 patch_cmi9880 [snd-hda-intel]: 108 124 : 16 pbus_size_mem [vmlinux]: 124 128 : 4 pkt_open [pktcdvd]: 556 560 : 4 prism2_plx_probe [hostap_plx]: 116 136 : 20 qla1280_nvram_config [qla1280]: 128 160 : 32 r300_do_cp_cmdbuf [radeon]: 580 572 : -8 radeon_check_modes [radeonfb]: 204 212 : 8 radeon_get_pllinfo [radeonfb]: 176 192 : 16 s2io_add_isr [s2io]: 176 184 : 8 savage_dispatch_draw [savage]: 304 308 : 4 sd_revalidate_disk [sd_mod]: 156 116 : -40 search_by_key [reiserfs]: 256 272 : 16 send_s870 [atp870u]: 100 104 : 4 service_interrupt [atmel]: 188 192 : 4 _snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4 snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36 snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8 snd_mixart_hw_params [snd-mixart]: 268 272 : 4 snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4 snd_pcm_hw_refine [snd-pcm]: 160 168 : 8 snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8 snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4 sr_probe [sr_mod]: 140 144 : 4 start_preview [saa7134]: 212 232 : 20 st_ioctl [st]: 128 144 : 16 stv680_newframe [stv680]: 176 192 : 16 svcauth_gss_accept [auth_rpcgss]: 216 208 : -8 sys_copyarea [syscopyarea]: 144 140 : -4 sys_init_module [vmlinux]: 232 236 : 4 tcp_sendmsg [vmlinux]: 128 120 : -8 tcp_v4_do_rcv [vmlinux]: 104 108 : 4 tulip_init_one [tulip]: 136 140 : 4 tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8 txCommit [jfs]: 168 180 : 12 udf_get_block [udf]: 412 416 : 4 udf_get_filename [udf]: 584 580 : -4 write_filehandle [nfsd]: 208 204 : -4 xfs_alloc_delrec [xfs]: 132 144 : 12 xfs_bmap_btalloc [xfs]: 172 180 : 8 xfs_bmbt_delrec [xfs]: 212 216 : 4 xfs_bmbt_newroot [xfs]: 132 140 : 8 xfs_da_do_buf [xfs]: 188 192 : 4 xfs_inobt_delrec [xfs]: 148 152 : 4 xfs_inobt_newroot [xfs]: 172 176 : 4 xtSearch [jfs]: 104 116 : 12 xtUpdate [jfs]: 404 424 : 20 zd1201_usbrx [zd1201]: 100 108 : 8 ------------------------ Functions increased: 79 Functions decreased: 25 Net change: +432 bytes that starts with checkstack output, so it's only checking functions using > 100 bytes of stack, and then the above is only showing functions with changed stack usage... but from a spot-check, smaller stack-users are affected as well. With 4KSTACKS on x86, I'm afraid this could add up to more problems. Any idea what might be causing this? Thanks, -Eric From jakub at redhat.com Fri Aug 24 13:59:47 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 24 Aug 2007 09:59:47 -0400 Subject: gcc in f8/x86 using more stack than in rhel5? In-Reply-To: <46CDFA29.9010801@redhat.com> References: <46CDFA29.9010801@redhat.com> Message-ID: <20070824135947.GG2063@devserv.devel.redhat.com> On Thu, Aug 23, 2007 at 04:20:41PM -0500, Eric Sandeen wrote: > I did a quick experiment, and it seems that by and large, gcc in f8 (gcc > version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack > when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105 > (Red Hat 4.1.1-52)) There are a few functions using less, too, though. > > After much checkstack output frobbing: > > function [module] : old : new : delta > -------------------------------------- > acpi_add_single_object [vmlinux]: 156 160 : 4 > acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4 > adi_connect [adi]: 144 148 : 4 > aes_decrypt [aes]: 140 144 : 4 > ahc_pci_config [aic7xxx]: 152 148 : -4 > ata_do_eh [libata]: 292 304 : 12 > aty128_probe [aty128fb]: 272 276 : 4 > balance_internal [reiserfs]: 148 160 : 12 > bond_arp_send_all [bonding]: 132 136 : 4 > capidtmf_recv_block [divacapi]: 188 192 : 4 > cciss_update_non_disk_devices [cciss]: 548 552 : 4 > cfb_copyarea [vmlinux]: 148 144 : -4 > check_balance [reiserfs]: 268 272 : 4 > copy_to_user_tmpl [vmlinux]: 400 404 : 4 > ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4 > decode_rs16 [reed_solomon]: 220 224 : 4 > diNewExt [jfs]: 112 108 : -4 > diva_add_card [divacapi]: 144 156 : 12 > do_balance [reiserfs]: 308 320 : 12 > do_cciss_request [cciss]: 544 548 : 4 > do_con_write [vmlinux]: 160 156 : -4 > do_tx [eni]: 120 124 : 4 > ea_dealloc_unstuffed [gfs2]: 116 120 : 4 > ehci_urb_enqueue [ehci-hcd]: 196 212 : 16 > ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4 > ext4_ext_insert_extent [ext4dev]: 144 148 : 4 > ext4_ext_remove_space [ext4dev]: 120 124 : 4 > facility_req [divacapi]: 396 392 : -4 > __fat_readdir [fat]: 252 256 : 4 > fat_search_long [fat]: 408 412 : 4 > fetch_frame [cpia]: 184 196 : 12 > ftdi_elan_status_work [ftdi-elan]: 252 248 : -4 > gdth_detect [gdth]: 440 436 : -4 > get_far_parent [reiserfs]: 140 152 : 12 > hfcpci_interrupt [hisax]: 356 360 : 4 > hptiop_probe [hptiop]: 152 156 : 4 > huft_build [vmlinux]: 152 144 : -8 > ieee80211_master_start_xmit [mac80211]: 176 180 : 4 > ieee80211_sta_work [mac80211]: 464 476 : 12 > i_ipmi_request [ipmi_msghandler]: 108 100 : -8 > inftl_scan_bbt [diskonchip]: 196 200 : 4 > ip_route_input [vmlinux]: 196 192 : -4 > ip_setsockopt [vmlinux]: 448 452 : 4 > isdn_tty_write [isdn]: 160 164 : 4 > ivtv_process_vbi_data [ivtv]: 116 120 : 4 > jfs_readdir [jfs]: 348 340 : -8 > key_schedule [cast5]: 608 596 : -12 > matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4 > matroxfb_ioctl [matroxfb_base]: 136 140 : 4 > mmc_blk_issue_rq [mmc_block]: 360 356 : -4 > module_verify_signature [vmlinux]: 124 120 : -4 > myri10ge_xmit [myri10ge]: 112 116 : 4 > nv_tx_timeout [forcedeth]: 156 144 : -12 > ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4 > os_scsi_tape_open [osst]: 180 184 : 4 > paging32_page_fault [kvm]: 116 108 : -8 > parse_audio_unit [snd-usb-audio]: 132 144 : 12 > patch_cmi9880 [snd-hda-intel]: 108 124 : 16 > pbus_size_mem [vmlinux]: 124 128 : 4 > pkt_open [pktcdvd]: 556 560 : 4 > prism2_plx_probe [hostap_plx]: 116 136 : 20 > qla1280_nvram_config [qla1280]: 128 160 : 32 > r300_do_cp_cmdbuf [radeon]: 580 572 : -8 > radeon_check_modes [radeonfb]: 204 212 : 8 > radeon_get_pllinfo [radeonfb]: 176 192 : 16 > s2io_add_isr [s2io]: 176 184 : 8 > savage_dispatch_draw [savage]: 304 308 : 4 > sd_revalidate_disk [sd_mod]: 156 116 : -40 > search_by_key [reiserfs]: 256 272 : 16 > send_s870 [atp870u]: 100 104 : 4 > service_interrupt [atmel]: 188 192 : 4 > _snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4 > snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36 > snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8 > snd_mixart_hw_params [snd-mixart]: 268 272 : 4 > snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4 > snd_pcm_hw_refine [snd-pcm]: 160 168 : 8 > snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8 > snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4 > sr_probe [sr_mod]: 140 144 : 4 > start_preview [saa7134]: 212 232 : 20 > st_ioctl [st]: 128 144 : 16 > stv680_newframe [stv680]: 176 192 : 16 > svcauth_gss_accept [auth_rpcgss]: 216 208 : -8 > sys_copyarea [syscopyarea]: 144 140 : -4 > sys_init_module [vmlinux]: 232 236 : 4 > tcp_sendmsg [vmlinux]: 128 120 : -8 > tcp_v4_do_rcv [vmlinux]: 104 108 : 4 > tulip_init_one [tulip]: 136 140 : 4 > tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8 > txCommit [jfs]: 168 180 : 12 > udf_get_block [udf]: 412 416 : 4 > udf_get_filename [udf]: 584 580 : -4 > write_filehandle [nfsd]: 208 204 : -4 > xfs_alloc_delrec [xfs]: 132 144 : 12 > xfs_bmap_btalloc [xfs]: 172 180 : 8 > xfs_bmbt_delrec [xfs]: 212 216 : 4 > xfs_bmbt_newroot [xfs]: 132 140 : 8 > xfs_da_do_buf [xfs]: 188 192 : 4 > xfs_inobt_delrec [xfs]: 148 152 : 4 > xfs_inobt_newroot [xfs]: 172 176 : 4 > xtSearch [jfs]: 104 116 : 12 > xtUpdate [jfs]: 404 424 : 20 > zd1201_usbrx [zd1201]: 100 108 : 8 > ------------------------ > Functions increased: 79 > Functions decreased: 25 > Net change: +432 bytes > > > that starts with checkstack output, so it's only checking functions > using > 100 bytes of stack, and then the above is only showing functions > with changed stack usage... but from a spot-check, smaller stack-users > are affected as well. > > With 4KSTACKS on x86, I'm afraid this could add up to more problems. > > Any idea what might be causing this? At least for the 4 testcases you've mailed me, there are two different causes: 1) http://gcc.gnu.org/PR30364 2) http://gcc.gnu.org/PR30931 E.g. snd_emu10k1_init_efx growth is caused by 1), while qla1280_nvram_config by 2), the other two I believe are caused by both together. PR30364 is a fix for when -fwrapv isn't used (but that option on the other hand can pessimize loops), it is unsafe to reassociate additions/subtractions if the type doesn't have defined overflow behavior. Say with int a, b, (a - 20) + (b - 20) is unsafe to reassociate into a + b - 40, because for certain values of a and b the former wouldn't overflow while the latter will. In the qla1280_nvram_config case this is with pointers which at least as richi wrote the patch are considered also to have undefined overflow behavior. But gcc 4.1.x/4.2.x (unlike the trunk) still reassociate e.g. struct A { unsigned int a, b, c; }; struct B { struct A d[12]; }; struct A * foo (struct B *x, int y) { return &x->d[y - 8]; } Jakub From sandeen at redhat.com Fri Aug 24 16:51:18 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 24 Aug 2007 11:51:18 -0500 Subject: gcc in f8/x86 using more stack than in rhel5? In-Reply-To: <20070824135947.GG2063@devserv.devel.redhat.com> References: <46CDFA29.9010801@redhat.com> <20070824135947.GG2063@devserv.devel.redhat.com> Message-ID: <46CF0C86.8010607@redhat.com> Jakub Jelinek wrote: > On Thu, Aug 23, 2007 at 04:20:41PM -0500, Eric Sandeen wrote: >> I did a quick experiment, and it seems that by and large, gcc in f8 (gcc >> version 4.1.2 20070821 (Red Hat 4.1.2-19)) is using slightly more stack >> when building a kernel than is gcc on rhel5 (gcc version 4.1.1 20070105 >> (Red Hat 4.1.1-52)) There are a few functions using less, too, though. >> >> After much checkstack output frobbing: >> >> function [module] : old : new : delta >> -------------------------------------- >> acpi_add_single_object [vmlinux]: 156 160 : 4 >> acpi_cpufreq_cpu_init [acpi-cpufreq]: 136 140 : 4 >> adi_connect [adi]: 144 148 : 4 >> aes_decrypt [aes]: 140 144 : 4 >> ahc_pci_config [aic7xxx]: 152 148 : -4 >> ata_do_eh [libata]: 292 304 : 12 >> aty128_probe [aty128fb]: 272 276 : 4 >> balance_internal [reiserfs]: 148 160 : 12 >> bond_arp_send_all [bonding]: 132 136 : 4 >> capidtmf_recv_block [divacapi]: 188 192 : 4 >> cciss_update_non_disk_devices [cciss]: 548 552 : 4 >> cfb_copyarea [vmlinux]: 148 144 : -4 >> check_balance [reiserfs]: 268 272 : 4 >> copy_to_user_tmpl [vmlinux]: 400 404 : 4 >> ctnetlink_new_expect [nf_conntrack_netlink]: 232 236 : 4 >> decode_rs16 [reed_solomon]: 220 224 : 4 >> diNewExt [jfs]: 112 108 : -4 >> diva_add_card [divacapi]: 144 156 : 12 >> do_balance [reiserfs]: 308 320 : 12 >> do_cciss_request [cciss]: 544 548 : 4 >> do_con_write [vmlinux]: 160 156 : -4 >> do_tx [eni]: 120 124 : 4 >> ea_dealloc_unstuffed [gfs2]: 116 120 : 4 >> ehci_urb_enqueue [ehci-hcd]: 196 212 : 16 >> ext4_expand_extra_isize_ea [ext4dev]: 128 132 : 4 >> ext4_ext_insert_extent [ext4dev]: 144 148 : 4 >> ext4_ext_remove_space [ext4dev]: 120 124 : 4 >> facility_req [divacapi]: 396 392 : -4 >> __fat_readdir [fat]: 252 256 : 4 >> fat_search_long [fat]: 408 412 : 4 >> fetch_frame [cpia]: 184 196 : 12 >> ftdi_elan_status_work [ftdi-elan]: 252 248 : -4 >> gdth_detect [gdth]: 440 436 : -4 >> get_far_parent [reiserfs]: 140 152 : 12 >> hfcpci_interrupt [hisax]: 356 360 : 4 >> hptiop_probe [hptiop]: 152 156 : 4 >> huft_build [vmlinux]: 152 144 : -8 >> ieee80211_master_start_xmit [mac80211]: 176 180 : 4 >> ieee80211_sta_work [mac80211]: 464 476 : 12 >> i_ipmi_request [ipmi_msghandler]: 108 100 : -8 >> inftl_scan_bbt [diskonchip]: 196 200 : 4 >> ip_route_input [vmlinux]: 196 192 : -4 >> ip_setsockopt [vmlinux]: 448 452 : 4 >> isdn_tty_write [isdn]: 160 164 : 4 >> ivtv_process_vbi_data [ivtv]: 116 120 : 4 >> jfs_readdir [jfs]: 348 340 : -8 >> key_schedule [cast5]: 608 596 : -12 >> matroxfb_dh_set_par [matroxfb_crtc2]: 116 120 : 4 >> matroxfb_ioctl [matroxfb_base]: 136 140 : 4 >> mmc_blk_issue_rq [mmc_block]: 360 356 : -4 >> module_verify_signature [vmlinux]: 124 120 : -4 >> myri10ge_xmit [myri10ge]: 112 116 : 4 >> nv_tx_timeout [forcedeth]: 156 144 : -12 >> ocfs2_write_cluster_by_desc [ocfs2]: 112 108 : -4 >> os_scsi_tape_open [osst]: 180 184 : 4 >> paging32_page_fault [kvm]: 116 108 : -8 >> parse_audio_unit [snd-usb-audio]: 132 144 : 12 >> patch_cmi9880 [snd-hda-intel]: 108 124 : 16 >> pbus_size_mem [vmlinux]: 124 128 : 4 >> pkt_open [pktcdvd]: 556 560 : 4 >> prism2_plx_probe [hostap_plx]: 116 136 : 20 >> qla1280_nvram_config [qla1280]: 128 160 : 32 >> r300_do_cp_cmdbuf [radeon]: 580 572 : -8 >> radeon_check_modes [radeonfb]: 204 212 : 8 >> radeon_get_pllinfo [radeonfb]: 176 192 : 16 >> s2io_add_isr [s2io]: 176 184 : 8 >> savage_dispatch_draw [savage]: 304 308 : 4 >> sd_revalidate_disk [sd_mod]: 156 116 : -40 >> search_by_key [reiserfs]: 256 272 : 16 >> send_s870 [atp870u]: 100 104 : 4 >> service_interrupt [atmel]: 188 192 : 4 >> _snd_emu10k1_audigy_init_efx [snd-emu10k1]: 160 164 : 4 >> snd_emu10k1_init_efx [snd-emu10k1]: 136 172 : 36 >> snd_intel8x0_probe [snd-intel8x0]: 156 148 : -8 >> snd_mixart_hw_params [snd-mixart]: 268 272 : 4 >> snd_pcm_common_ioctl1 [snd-pcm]: 272 276 : 4 >> snd_pcm_hw_refine [snd-pcm]: 160 168 : 8 >> snd_pcm_oss_change_params [snd-pcm-oss]: 168 176 : 8 >> snd_usb_create_midi_interface [snd-usb-lib]: 112 116 : 4 >> sr_probe [sr_mod]: 140 144 : 4 >> start_preview [saa7134]: 212 232 : 20 >> st_ioctl [st]: 128 144 : 16 >> stv680_newframe [stv680]: 176 192 : 16 >> svcauth_gss_accept [auth_rpcgss]: 216 208 : -8 >> sys_copyarea [syscopyarea]: 144 140 : -4 >> sys_init_module [vmlinux]: 232 236 : 4 >> tcp_sendmsg [vmlinux]: 128 120 : -8 >> tcp_v4_do_rcv [vmlinux]: 104 108 : 4 >> tulip_init_one [tulip]: 136 140 : 4 >> tveeprom_hauppauge_analog [tveeprom]: 156 164 : 8 >> txCommit [jfs]: 168 180 : 12 >> udf_get_block [udf]: 412 416 : 4 >> udf_get_filename [udf]: 584 580 : -4 >> write_filehandle [nfsd]: 208 204 : -4 >> xfs_alloc_delrec [xfs]: 132 144 : 12 >> xfs_bmap_btalloc [xfs]: 172 180 : 8 >> xfs_bmbt_delrec [xfs]: 212 216 : 4 >> xfs_bmbt_newroot [xfs]: 132 140 : 8 >> xfs_da_do_buf [xfs]: 188 192 : 4 >> xfs_inobt_delrec [xfs]: 148 152 : 4 >> xfs_inobt_newroot [xfs]: 172 176 : 4 >> xtSearch [jfs]: 104 116 : 12 >> xtUpdate [jfs]: 404 424 : 20 >> zd1201_usbrx [zd1201]: 100 108 : 8 >> ------------------------ >> Functions increased: 79 >> Functions decreased: 25 >> Net change: +432 bytes >> >> >> that starts with checkstack output, so it's only checking functions >> using > 100 bytes of stack, and then the above is only showing functions >> with changed stack usage... but from a spot-check, smaller stack-users >> are affected as well. >> >> With 4KSTACKS on x86, I'm afraid this could add up to more problems. >> >> Any idea what might be causing this? > > At least for the 4 testcases you've mailed me, there are two different > causes: > 1) http://gcc.gnu.org/PR30364 > 2) http://gcc.gnu.org/PR30931 > > E.g. snd_emu10k1_init_efx growth is caused by 1), while qla1280_nvram_config > by 2), the other two I believe are caused by both together. Any desire to look at some of the smaller deltas, or do you think it's likely that they are the same issues? (I think I can find some simple functions with small stack deltas, if you'd like). Thanks for looking at this, -Eric From jwilson at redhat.com Sat Aug 25 04:48:00 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 25 Aug 2007 00:48:00 -0400 Subject: [RFC PATCH] lirc IR receiver drivers Message-ID: <46CFB480.6010700@redhat.com> Hey all, So... As I've mentioned on various forums here and there in the recent past, I'd really like to see fedora carry the lirc drivers (http://www.lirc.org/) in-kernel, and help push them into the upstream kernel. I finally got around to doing something significant about it this evening. The link below is the completion of my first attempt at a patch tailored for upstream, based partially on work done by Mario Limonciello for Ubuntu (cc'd). http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch It includes all the latest bits from lirc cvs, save the lirc_gpio driver, which doesn't compile of late, but restructures the code in a few ways: 1) header include paths have been altered to match the file layout as patched into the kernel tree 2) in theory, all '#if LINUX_VERSION_CODE' and similar bits have been eliminated, along with all code sections for older kernels dropped, which trims down the patch by over 1000 lines and definitely makes it more manageable. 3) a few minor changes from the upstream code base to compile with the latest rawhide gcc (a few "error: void value not ignored as it ought to be" messages, which I've not yet properly fixed). -- I've done a local x86_64 test build with this patch against 2.6.23-rc3-git6, which upon initial inspection, looks good, though I have yet to try it out on actual hardware (on my todo list this weekend). See resulting build file listing below. If deemed appropriate, I'd like to slap this patch into the rawhide kernel builds as soon as possible. Would also rather like to get it into F7 and FC6 kernels after its had a bit of soak time... Next up, I'd like to get the patch broken up into manageable chunks and sent off to lkml for review so we can get this thing up to kernel coding standards and hopefully included in the kernel proper. $ rpm -qpl RPMS/x86_64/kernel-2.6.23-0.133.rc3.git6.lirc1.fc8.x86_64.rpm | grep -e 'lirc_.*.ko' /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_atiusb/lirc_atiusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_bt829/lirc_bt829.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/commandir.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/lirc_cmdir.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_dev/lirc_dev.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_i2c/lirc_i2c.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_igorplugusb/lirc_igorplugusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_imon/lirc_imon.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_it87/lirc_it87.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb/lirc_mceusb.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb2/lirc_mceusb2.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_pvr150/lirc_pvr150.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_serial/lirc_serial.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_sir/lirc_sir.ko/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc7/kernel/drivers/input/lirc/lirc_streamzap/lirc_streamzap.ko /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_ttusbir/lirc_ttusbir.ko Thanks for listening, time for z's... -- Jarod Wilson jwilson at redhat.com From superm1 at ubuntu.com Sat Aug 25 06:16:59 2007 From: superm1 at ubuntu.com (Mario Limonciello) Date: Sat, 25 Aug 2007 01:16:59 -0500 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46CFB480.6010700@redhat.com> References: <46CFB480.6010700@redhat.com> Message-ID: <46CFC95B.8060409@ubuntu.com> Jarod Wilson wrote: > Hey all, > > So... As I've mentioned on various forums here and there in the recent > past, I'd really like to see fedora carry the lirc drivers > (http://www.lirc.org/) in-kernel, and help push them into the upstream > kernel. I finally got around to doing something significant about it > this evening. The link below is the completion of my first attempt at a > patch tailored for upstream, based partially on work done by Mario > Limonciello for Ubuntu (cc'd). > > http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch > > It includes all the latest bits from lirc cvs, save the lirc_gpio > driver, which doesn't compile of late, but restructures the code in a > few ways: > > 1) header include paths have been altered to match the file layout as > patched into the kernel tree > > 2) in theory, all '#if LINUX_VERSION_CODE' and similar bits have been > eliminated, along with all code sections for older kernels dropped, > which trims down the patch by over 1000 lines and definitely makes it > more manageable. > > 3) a few minor changes from the upstream code base to compile with the > latest rawhide gcc (a few "error: void value not ignored as it ought to > be" messages, which I've not yet properly fixed). > > -- > > I've done a local x86_64 test build with this patch against > 2.6.23-rc3-git6, which upon initial inspection, looks good, though I > have yet to try it out on actual hardware (on my todo list this > weekend). See resulting build file listing below. > > If deemed appropriate, I'd like to slap this patch into the rawhide > kernel builds as soon as possible. Would also rather like to get it into > F7 and FC6 kernels after its had a bit of soak time... > > Next up, I'd like to get the patch broken up into manageable chunks and > sent off to lkml for review so we can get this thing up to kernel coding > standards and hopefully included in the kernel proper. > > $ rpm -qpl RPMS/x86_64/kernel-2.6.23-0.133.rc3.git6.lirc1.fc8.x86_64.rpm > | grep -e 'lirc_.*.ko' > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_atiusb/lirc_atiusb.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_bt829/lirc_bt829.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/commandir.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_cmdir/lirc_cmdir.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_dev/lirc_dev.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_i2c/lirc_i2c.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_igorplugusb/lirc_igorplugusb.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_imon/lirc_imon.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_it87/lirc_it87.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb/lirc_mceusb.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_mceusb2/lirc_mceusb2.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_pvr150/lirc_pvr150.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_serial/lirc_serial.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_sir/lirc_sir.ko/lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc7/kernel/drivers/input/lirc/lirc_streamzap/lirc_streamzap.ko > > /lib/modules/2.6.23-0.133.rc3.git6.lirc1.fc8/kernel/drivers/input/lirc/lirc_ttusbir/lirc_ttusbir.ko > > > Thanks for listening, time for z's... > Note also, lirc-pvr150 hasn't been submitted upstream to lirc for some reason or another. It really should be in the near future. Mario Limonciello superm1 at ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From sandeen at redhat.com Sat Aug 25 06:26:43 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 25 Aug 2007 01:26:43 -0500 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46CFB480.6010700@redhat.com> References: <46CFB480.6010700@redhat.com> Message-ID: <46CFCBA3.2050506@redhat.com> Jarod Wilson wrote: > Hey all, > > So... As I've mentioned on various forums here and there in the recent > past, I'd really like to see fedora carry the lirc drivers > (http://www.lirc.org/) in-kernel, and help push them into the upstream > kernel. I finally got around to doing something significant about it > this evening. The link below is the completion of my first attempt at a > patch tailored for upstream, based partially on work done by Mario > Limonciello for Ubuntu (cc'd). > > http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch Cool, I tossed a few build-related fixes (warnings, deprecated interfaces/flags, etc..) on top of this up at http://people.redhat.com/esandeen/lirc/ (There's also usb stuff going on I don't understand in the commandir driver :) but with the warning about the callback it will probably explode when run.) Also given that each subdir under drivers/input/lirc generally has just one .c file, I'd probably flatten it out, and drop everything into drivers/input/lirc/*.c Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - perhaps each individual driver should just do "select LIRC_DEV" rather than "depends on?" and remove the prompt for LIRC_DEV? -Eric From sandeen at redhat.com Sat Aug 25 07:27:50 2007 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 25 Aug 2007 02:27:50 -0500 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46CFCBA3.2050506@redhat.com> References: <46CFB480.6010700@redhat.com> <46CFCBA3.2050506@redhat.com> Message-ID: <46CFD9F6.2020301@redhat.com> Eric Sandeen wrote: > Also given that each subdir under drivers/input/lirc generally has just > one .c file, I'd probably flatten it out, and drop everything into > drivers/input/lirc/*.c Until then, I tossed up a kbuild patch that will get make O=foo M=drivers/input/lirc working properly too (kbuild didn't like the files-in-subdirs when building with an object tree... unless I've forgotten any kbuild-foo I ever had). :) -Eric From jwilson at redhat.com Sun Aug 26 01:09:05 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 25 Aug 2007 21:09:05 -0400 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46CFCBA3.2050506@redhat.com> References: <46CFB480.6010700@redhat.com> <46CFCBA3.2050506@redhat.com> Message-ID: <46D0D2B1.3090306@redhat.com> Eric Sandeen wrote: > Jarod Wilson wrote: >> Hey all, >> >> So... As I've mentioned on various forums here and there in the recent >> past, I'd really like to see fedora carry the lirc drivers >> (http://www.lirc.org/) in-kernel, and help push them into the upstream >> kernel. I finally got around to doing something significant about it >> this evening. The link below is the completion of my first attempt at a >> patch tailored for upstream, based partially on work done by Mario >> Limonciello for Ubuntu (cc'd). >> >> http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch > > Cool, I tossed a few build-related fixes (warnings, deprecated > interfaces/flags, etc..) on top of this up at > > http://people.redhat.com/esandeen/lirc/ Very nice. Gah, at least one of those fixes some things I screwed up merging in the latest bits from cvs... > (There's also usb stuff going on I don't understand in the commandir > driver :) but with the warning about the callback it will probably > explode when run.) Hrm, that's not so good... I was thinking of seeing if I could find one somewhere for cheap, but ouch, those things look pricey... http://www.commandir.com/order/ > Also given that each subdir under drivers/input/lirc generally has just > one .c file, I'd probably flatten it out, and drop everything into > drivers/input/lirc/*.c Yeah, that idea crossed my mind too after I'd sent the mail off before drifting off to sleep. I'll do that for the next rendition. > Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - > perhaps each individual driver should just do "select LIRC_DEV" rather > than "depends on?" and remove the prompt for LIRC_DEV? Sounds like a good idea to me. -- Jarod Wilson jwilson at redhat.com From j.w.r.degoede at hhs.nl Mon Aug 27 10:07:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Aug 2007 12:07:01 +0200 Subject: Need to use i586 kernel and i386 glibc for via c7 epia system Message-ID: <46D2A245.2090803@hhs.nl> Hi all, A bit offtopic for this list, but this is the best place I could think of to discuss this. A friend of mine had trouble with 2 different via c7 epia motherboards (mini itx boards with single chip chipset with unichrome integrated graphics) machines. They would freeze (hard) pretty much at random while working in programs like openoffice or firefox. He end up writing a script which would repeatedly start firefox and thunderbird, wait for the cpu load to become zero, kill them again, etc. This killed the system reproducable, usually within the hour, always within 5 hours. He gave one to me with the request to see if I could fix it. After many days of experimenting (latest bios update, try various settings, verify cooling, etc), I've found out that (on a fully up2date Fedora 7 system) replacing the i686 kernel with the i586 one and the glibc with the i386 (and openssl, but that wasn't used afaik) will make the system stable. So appearantly the via c7 isn't all that i686 compatible as via claims, I suspect that there may be a problem with certain i686 specific synchronisation instructions, but that is just a hunge. This leads to the conclusion, that anacondo should perhaps be modified to mark these systems as i586 and thus choose a i586 kernel and a i386 glibc when installing on them. But before filing a but I first wanted to discuss this here. Regards, Hans From nicolas.mailhot at laposte.net Mon Aug 27 10:41:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Aug 2007 12:41:57 +0200 (CEST) Subject: Need to use i586 kernel and i386 glibc for via c7 epia system In-Reply-To: <46D2A245.2090803@hhs.nl> References: <46D2A245.2090803@hhs.nl> Message-ID: <60378.192.54.193.51.1188211317.squirrel@rousalka.dyndns.org> Le Lun 27 ao?t 2007 12:07, Hans de Goede a ?crit : > Hi all, > > A bit offtopic for this list, but this is the best place I could think > of to discuss this. ... > So appearantly the via c7 isn't all that i686 compatible as via > claims As Alan will likely repeat, the glibc definition of i686 is not conformant with the Intel definition of i686. It includes instructions Intel declared optional, and Via does not implement. So a glibc i686 binary won't run on all the i686 processors on the market. -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Mon Aug 27 10:38:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Aug 2007 12:38:55 +0200 Subject: Need to use i586 kernel and i386 glibc for via c7 epia system In-Reply-To: <60378.192.54.193.51.1188211317.squirrel@rousalka.dyndns.org> References: <46D2A245.2090803@hhs.nl> <60378.192.54.193.51.1188211317.squirrel@rousalka.dyndns.org> Message-ID: <46D2A9BF.30600@hhs.nl> Nicolas Mailhot wrote: > Le Lun 27 ao?t 2007 12:07, Hans de Goede a ?crit : >> Hi all, >> >> A bit offtopic for this list, but this is the best place I could think >> of to discuss this. > > ... > >> So appearantly the via c7 isn't all that i686 compatible as via >> claims > > As Alan will likely repeat, the glibc definition of i686 is not > conformant with the Intel definition of i686. It includes instructions > Intel declared optional, and Via does not implement. So a glibc i686 > binary won't run on all the i686 processors on the market. > I know, but this is a via C7 (not a C3) which _does_ implement the instructions to match the rpm definition of i686 (which means it does implement cmov), but appearantly it doesn't implement them too well. Regards, Hans From trond.myklebust at fys.uio.no Mon Aug 27 13:19:33 2007 From: trond.myklebust at fys.uio.no (Trond Myklebust) Date: Mon, 27 Aug 2007 09:19:33 -0400 Subject: The NFS "nosharecache" patch in F7 is broken In-Reply-To: <46CB0F63.7050609@RedHat.com> References: <46CAF6E1.1030702@redhat.com> <20070821155149.GA30242@redhat.com> <46CB0F63.7050609@RedHat.com> Message-ID: <1188220773.6701.36.camel@heimdal.trondhjem.org> On Tue, 2007-08-21 at 12:14 -0400, Steve Dickson wrote: > > Dave Jones wrote: > > On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote: > > > If people try mounting several exports from the same filesystem, it fails > > > with confusing error messages if the mount options are different for some > > > of the mount points. Adding "nosharecache" to the mount options fixes that, > > > but people with working setups suddenly find they need this new option to > > > use a setup that used to work without it. Should we just revert that patch? > Thats been the million dollar question lately... there has been quite a > bit of complaints about this patch... but note the check does do some > correct sanity checking so the changes it point would be a good > thing to do.... > > But with that said, I would if making it a warning first, giving > people time to clean up their setups and then making it an > error later on... > > steved. It is important that people know about the consequences of using nosharecache: namely that they may see cache corruption when accessing the same file via different mountpoints. That is why I firmly believe it should _NOT_ be a default. Trond From jwilson at redhat.com Mon Aug 27 15:19:40 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 27 Aug 2007 11:19:40 -0400 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46D0D2B1.3090306@redhat.com> References: <46CFB480.6010700@redhat.com> <46CFCBA3.2050506@redhat.com> <46D0D2B1.3090306@redhat.com> Message-ID: <46D2EB8C.8060905@redhat.com> Jarod Wilson wrote: > Eric Sandeen wrote: >> Jarod Wilson wrote: >>> Hey all, >>> >>> So... As I've mentioned on various forums here and there in the >>> recent past, I'd really like to see fedora carry the lirc drivers >>> (http://www.lirc.org/) in-kernel, and help push them into the >>> upstream kernel. I finally got around to doing something significant >>> about it this evening. The link below is the completion of my first >>> attempt at a patch tailored for upstream, based partially on work >>> done by Mario Limonciello for Ubuntu (cc'd). >>> >>> http://people.redhat.com/jwilson/lirc/linux-2.6-lirc.patch >> >> Cool, I tossed a few build-related fixes (warnings, deprecated >> interfaces/flags, etc..) on top of this up at >> >> http://people.redhat.com/esandeen/lirc/ > > Very nice. Gah, at least one of those fixes some things I screwed up > merging in the latest bits from cvs... > >> (There's also usb stuff going on I don't understand in the commandir >> driver :) but with the warning about the callback it will probably >> explode when run.) > > Hrm, that's not so good... I was thinking of seeing if I could find one > somewhere for cheap, but ouch, those things look pricey... > > http://www.commandir.com/order/ > >> Also given that each subdir under drivers/input/lirc generally has just >> one .c file, I'd probably flatten it out, and drop everything into >> drivers/input/lirc/*.c > > Yeah, that idea crossed my mind too after I'd sent the mail off before > drifting off to sleep. I'll do that for the next rendition. > >> Also in Kconfig, INPUT_LIRC and LIRC_DEV seem a little redundant - >> perhaps each individual driver should just do "select LIRC_DEV" rather >> than "depends on?" and remove the prompt for LIRC_DEV? > > Sounds like a good idea to me. All of the work Eric and I did over the weekend is now in a proper git tree, which can be browsed (and cloned) here: http://git.wilsonet.com/linux-2.6-lirc.git/ A few more clean-ups and we'll slap this puppy into an actual rawhide kernel build to start getting some wider testing... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Mon Aug 27 21:49:08 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 27 Aug 2007 17:49:08 -0400 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46D2EB8C.8060905@redhat.com> References: <46CFB480.6010700@redhat.com> <46CFCBA3.2050506@redhat.com> <46D0D2B1.3090306@redhat.com> <46D2EB8C.8060905@redhat.com> Message-ID: <46D346D4.1050306@redhat.com> Jarod Wilson wrote: > All of the work Eric and I did over the weekend is now in a proper git > tree, which can be browsed (and cloned) here: > > http://git.wilsonet.com/linux-2.6-lirc.git/ I restructured the order of commits a bit, so if anyone did a checkout before noon eastern US time, you probably want to throw it away and start over. > A few more clean-ups and we'll slap this puppy into an actual rawhide > kernel build to start getting some wider testing... Its been added to the build, and is working its way through the build system right now. Local build worked, but that was just one arch and variant, so here's hoping it makes it through the gamut. Still need to get more feedback from upstream LIRC to see how they want to move forward with this (query submitted, awaiting reply), since the git tree is already starting to diverge a bit... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Tue Aug 28 01:58:10 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 27 Aug 2007 21:58:10 -0400 Subject: [RFC PATCH] lirc IR receiver drivers In-Reply-To: <46D346D4.1050306@redhat.com> References: <46CFB480.6010700@redhat.com> <46CFCBA3.2050506@redhat.com> <46D0D2B1.3090306@redhat.com> <46D2EB8C.8060905@redhat.com> <46D346D4.1050306@redhat.com> Message-ID: <46D38132.3040401@redhat.com> Jarod Wilson wrote: > Its been added to the build, and is working its way through the build > system right now. Local build worked, but that was just one arch and > variant, so here's hoping it makes it through the gamut. Ran into a hiccup on ppc64, but got that ironed out, and the second try just finished building for all arches and flavors. http://koji.fedoraproject.org/packages/kernel/2.6.23/0.142.rc3.git10.fc8/ -- Jarod Wilson jwilson at redhat.com From davej at redhat.com Wed Aug 29 19:05:31 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 29 Aug 2007 15:05:31 -0400 Subject: -vanilla builds. Message-ID: <20070829190531.GG31948@redhat.com> I'd like to move forward on us getting vanilla builds out for testers. There are a couple things worth thinking about, which I'd like other peoples thoughts on. * The location of the binaries - I think we ended up settling on putting them on people.fedoraproject.org. Given the 150MB quota, this probably means... - no -debuginfo packages. (not a huge deal) - probably just x86/x86-64 to begin with. - probably no non-debug variants (ie, same model as rawhide, with debug 'always on' - worth doing PAE and non-PAE ? just one? which? * how/where to building them. AFAIK, it isn't possible to pass switches like --with-vanilla to koji, so the two options are.. - build vanilla as part of the regular build (not a great idea, it already takes hours to build a complete set of kernels). - I kick off a bunch of rpmbuilds locally and push them by hand. (scriptable at least, so not such a big deal). I think this is the best option. * frequency of updates. I don't think it's really worthwhile doing daily builds. Doing at least one per -rc is probably a good target, with perhaps a -rcN-git build periodically if the next -rc is taking a while to land. * dependancies. This is the only remaining technical puzzle I think. I'd like the vanilla rpms to install on FC6, F7, and rawhide. Doing separate builds per distro is just going to kill me. The only thing stopping this from working is requires: lines like .. %define kernel_prereq fileutils, module-init-tools, initscripts >= %8.11.1-1, mkinitrd >= 6.0.9-7 I'm thinking perhaps something like.. %if ! %{with_vanilla} %define kernel_prereq fileutils, module-init-tools, initscripts >= %8.11.1-1, mkinitrd >= 6.0.9-7 %else %define kernel_prereq fileutils, module-init-tools, initscripts, mkinitrd %endif might do the trick. However for some cases, those versioned dependancies are there for a reason, and I'm not entirely sure what to do about them. I'd rather not have to build non-kernel packages for the vanilla repo too. Ideas ? Ideally I'd like to get to a state where these are built by a cronjob on my desktop that checks for a new rc, and uploads new updates whilst I sleep^Wdo something else. Dave -- http://www.codemonkey.org.uk From tibbs at math.uh.edu Wed Aug 29 19:36:31 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Aug 2007 14:36:31 -0500 Subject: -vanilla builds. In-Reply-To: <20070829190531.GG31948@redhat.com> References: <20070829190531.GG31948@redhat.com> Message-ID: >>>>> "DJ" == Dave Jones writes: DJ> I think we ended up settling on putting them on DJ> people.fedoraproject.org. Given the 150MB quota, this probably DJ> means... Actually all it means is that you need to ask for more space. - J< From notting at redhat.com Wed Aug 29 20:14:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 29 Aug 2007 16:14:06 -0400 Subject: -vanilla builds. In-Reply-To: References: <20070829190531.GG31948@redhat.com> Message-ID: <20070829201406.GA25246@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > >>>>> "DJ" == Dave Jones writes: > > DJ> I think we ended up settling on putting them on > DJ> people.fedoraproject.org. Given the 150MB quota, this probably > DJ> means... > > Actually all it means is that you need to ask for more space. Sort of. Adding debuginfo + all arches means that each vanilla build could end up taking up over a gigabyte. There are limits to how much space we can ask for. Bill From davej at redhat.com Wed Aug 29 20:45:27 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 29 Aug 2007 16:45:27 -0400 Subject: bugzilla triage. Message-ID: <20070829204527.GA27594@redhat.com> The current state of bugzilla for the kernel is pretty depressing. Counting in all the bugs we never fixed for FC5 (a lot of which are probably still valid for everything through to rawhide), there are around 1600 open bugs. In an attempt to disperse some of the 'triage' type work to volunteers, I've started a page at http://fedoraproject.org/wiki/KernelBugTriage with some simple things that people can do to help out. Any additions/improvements welcomed. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Aug 30 04:52:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Aug 2007 06:52:41 +0200 Subject: -vanilla builds. In-Reply-To: <20070829190531.GG31948@redhat.com> References: <20070829190531.GG31948@redhat.com> Message-ID: <46D64D19.6080803@leemhuis.info> On 29.08.2007 21:05, Dave Jones wrote: > I'd like to move forward on us getting vanilla builds out for testers. I'm willing to help here if there is anything I can do. > There are a couple things worth thinking about, which I'd like other > peoples thoughts on. > > * The location of the binaries - I think we ended up settling > on putting them on people.fedoraproject.org. My vote is still to ship them in the proper repos -- an idea lot of people liked in last weeks discussion here. But people feared the space requirements. But that's a problem on p.f.o as well afaics. > * how/where to building them. > AFAIK, it isn't possible to pass switches like --with-vanilla > to koji, so the two options are.. > - build vanilla as part of the regular build > (not a great idea, it already takes hours to build > a complete set of kernels). How about a different package kernel-vanilla in CVS that can be build independently of the normal build? > [...] > * dependancies. > This is the only remaining technical puzzle I think. > I'd like the vanilla rpms to install on FC6, F7, and rawhide. > Doing separate builds per distro is just going to kill me. But often needed, as people otherwise often can't build kernel modules theirselfs, as GCC doesn't match (it does currently iirc, but often there are different major versions of gcc in the different distros. > [...] CU knurd From davej at redhat.com Thu Aug 30 05:03:27 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 30 Aug 2007 01:03:27 -0400 Subject: -vanilla builds. In-Reply-To: <46D64D19.6080803@leemhuis.info> References: <20070829190531.GG31948@redhat.com> <46D64D19.6080803@leemhuis.info> Message-ID: <20070830050327.GA16414@redhat.com> On Thu, Aug 30, 2007 at 06:52:41AM +0200, Thorsten Leemhuis wrote: > On 29.08.2007 21:05, Dave Jones wrote: > > I'd like to move forward on us getting vanilla builds out for testers. > > I'm willing to help here if there is anything I can do. > > > There are a couple things worth thinking about, which I'd like other > > peoples thoughts on. > > > > * The location of the binaries - I think we ended up settling > > on putting them on people.fedoraproject.org. > > My vote is still to ship them in the proper repos -- an idea lot of > people liked in last weeks discussion here. But people feared the space > requirements. But that's a problem on p.f.o as well afaics. Nearly everyone else I've talked to about this seems to be against that idea for whatever reasons. > > * how/where to building them. > > AFAIK, it isn't possible to pass switches like --with-vanilla > > to koji, so the two options are.. > > - build vanilla as part of the regular build > > (not a great idea, it already takes hours to build > > a complete set of kernels). > > How about a different package kernel-vanilla in CVS that can be build > independently of the normal build? This means committing rebases to >1 place, which sounds like losing. It doesn't really bring any advantages either afaics. > > [...] > > * dependancies. > > This is the only remaining technical puzzle I think. > > I'd like the vanilla rpms to install on FC6, F7, and rawhide. > > Doing separate builds per distro is just going to kill me. > > But often needed, as people otherwise often can't build kernel modules > theirselfs, as GCC doesn't match (it does currently iirc, but often > there are different major versions of gcc in the different distros. 3rd party modules for kernel-vanilla brings up an interesting question. For bugs found in kernel-vanilla, I want *everything* to go to linux-kernel or bugzilla.kernel.org. If reports there contain any out-of-tree modules, they'll get closed out no questions asked. AFAIAC, 3rd party modules are even less supportable on -vanilla than they are on the regular fedora kernel. For the minority that can't live without 3rd party modules, they can build their own kernels, because building a full set of kernels for each distro is time consuming enough that I only want to do this once. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Thu Aug 30 05:16:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 30 Aug 2007 07:16:40 +0200 Subject: -vanilla builds. In-Reply-To: <20070830050327.GA16414@redhat.com> References: <20070829190531.GG31948@redhat.com> <46D64D19.6080803@leemhuis.info> <20070830050327.GA16414@redhat.com> Message-ID: <46D652B8.1090803@leemhuis.info> On 30.08.2007 07:03, Dave Jones wrote: > On Thu, Aug 30, 2007 at 06:52:41AM +0200, Thorsten Leemhuis wrote: > > On 29.08.2007 21:05, Dave Jones wrote: > > > I'd like to move forward on us getting vanilla builds out for testers. > > > > I'm willing to help here if there is anything I can do. > > > > > There are a couple things worth thinking about, which I'd like other > > > peoples thoughts on. > > > > > > * The location of the binaries - I think we ended up settling > > > on putting them on people.fedoraproject.org. > > > > My vote is still to ship them in the proper repos -- an idea lot of > > people liked in last weeks discussion here. But people feared the space > > requirements. But that's a problem on p.f.o as well afaics. > > Nearly everyone else I've talked to about this seems to be > against that idea for whatever reasons. Hallway conversations :-/ I understand that it makes things easier often, but please share what you discussed and especially the outcome (like you did with that sentence above) with the public, so outside contributors don't feel like second class contributors whos opinion doesn't count. > > > * how/where to building them. > > > AFAIK, it isn't possible to pass switches like --with-vanilla > > > to koji, so the two options are.. > > > - build vanilla as part of the regular build > > > (not a great idea, it already takes hours to build > > > a complete set of kernels). > > > > How about a different package kernel-vanilla in CVS that can be build > > independently of the normal build? > > This means committing rebases to >1 place, which sounds like losing. > It doesn't really bring any advantages either afaics. Yeah, you have a point. > > > [...] > > > * dependancies. > > > This is the only remaining technical puzzle I think. > > > I'd like the vanilla rpms to install on FC6, F7, and rawhide. > > > Doing separate builds per distro is just going to kill me. > > > > But often needed, as people otherwise often can't build kernel modules > > theirselfs, as GCC doesn't match (it does currently iirc, but often > > there are different major versions of gcc in the different distros. > > 3rd party modules for kernel-vanilla brings up an interesting question. > For bugs found in kernel-vanilla, I want *everything* to go to > linux-kernel or bugzilla.kernel.org. +1 > If reports there contain > any out-of-tree modules, they'll get closed out no questions asked. > AFAIAC, 3rd party modules are even less supportable on -vanilla > than they are on the regular fedora kernel. > > For the minority that can't live without 3rd party modules, they > can build their own kernels, because building a full set of kernels > for each distro is time consuming enough that I only want to do > this once. I think you are making your life to easy here. CU knurd From acme at redhat.com Fri Aug 31 01:01:24 2007 From: acme at redhat.com (Arnaldo Carvalho de Melo) Date: Thu, 30 Aug 2007 22:01:24 -0300 Subject: -vanilla builds. In-Reply-To: <20070829201406.GA25246@nostromo.devel.redhat.com> References: <20070829190531.GG31948@redhat.com> <20070829201406.GA25246@nostromo.devel.redhat.com> Message-ID: <46D76864.7070803@redhat.com> Bill Nottingham wrote: > Jason L Tibbitts III (tibbs at math.uh.edu) said: > >>>>>>> "DJ" == Dave Jones writes: >>>>>>> >> DJ> I think we ended up settling on putting them on >> DJ> people.fedoraproject.org. Given the 150MB quota, this probably >> DJ> means... >> >> Actually all it means is that you need to ask for more space. >> > > Sort of. Adding debuginfo + all arches means that each vanilla > build could end up taking up over a gigabyte. There are limits > to how much space we can ask for. > > We have just to find a sucker to fix the DWARF mess that we have these days... hey, don't look at me... too closely... :-P - Arnaldo