Re: perfmon2 on fedora kernels
Ted Sume Nzuonkwelle wrote: Hi, My apologies if this is going to the wrong mailing list. Is there an easy way to enable support for perfmon2 in the fedora 9 kernel(s)? Looks like the patch for perfmon2 available at http://sourceforge.net/projects/perfmon2/ is only useful if patching a vanilla kernel? Any help and/pointers will be greatly appreciated. It shouldn't be too hard to get it working. You just need to fix up the parts that don't apply properly. We could put it in fedora but it's not upstream and nobody can say when or if it will go in. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: perfmon2 on fedora kernels
On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: > We could put it in fedora but it's not upstream and nobody can say when or if > it will go in. After the long drawn out pain that utrace has been, I'm somewhat reluctant. Especially for something that's providing additional userspace interfaces that aren't upstream. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: perfmon2 on fedora kernels
On Thu, Jul 31, 2008 at 02:31:33PM -0400, Dave Jones wrote: > On Thu, Jul 31, 2008 at 02:26:10PM -0400, Chuck Ebbert wrote: > > > We could put it in fedora but it's not upstream and nobody can say when or > if > > it will go in. > > After the long drawn out pain that utrace has been, I'm somewhat reluctant. > Especially for something that's providing additional userspace interfaces > that aren't upstream. > Perfmon adds a ridiculous number of syscalls, which means we *really* shouldn't merge it until they're reserved upstream, otherwise backwards compat woes will ensue. However, perfmon doesn't look like it is anywhere near being merged in the current form, so I'd rate it as unlikely upstream will reserve 10+ syscall entrypoints for it... NAK from me... cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [PATCH] kernel.spec: adding --with firmware & --without vdso_install build options
Steve Dickson wrote:
Now that devel kernels rpms require the kernel-firmware rpm, it makes
sense to me that one should be able to build both of them at the
same time. So this patch adds the "--with firmware" build option
which will allow kernel-firmware rpms to built with kernel rpms.
This patch also adds the "--without vdso_install" build option
which stop the VDSO binaries from being installed. This cuts
down the overall build time especially when you build over NFS
like I do..
Signed-Off-By: Steve Dickson <[EMAIL PROTECTED]>
With one small change we can still support --without firmware. That way
the default behavior can be overridden in either case. See below...
diff -up SPECS/kernel.spec.orig SPECS/kernel.spec
--- SPECS/kernel.spec.orig 2008-07-29 09:07:48.0 -0400
+++ SPECS/kernel.spec 2008-07-29 11:44:39.0 -0400
@@ -75,11 +75,13 @@ Summary: The Linux kernel
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
# kernel-firmware
-%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
+%define with_firmware %{?_with_firmware: 1} %{?!_with_firmware: 0}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
# kernel-bootwrapper (for creating zImages from kernel + initrd)
%define with_bootwrapper %{?_without_bootwrapper: 0} %{?!_without_bootwrapper:
1}
+# Want to build a the vsdo directories installed
+%define with_vdso_install %{?_without_vdso_install: 0}
%{?!_without_vdso_install: 1}
# don't build the kernel-doc package
%define with_doc 0
@@ -188,8 +190,10 @@ Summary: The Linux kernel
%define all_x86 i386 i586 i686
+%if %{with_vdso_install}
# These arches install vdso/ directories.
%define vdso_arches %{all_x86} x86_64 ppc ppc64
+%endif
# Overrides for generic default options
@@ -217,7 +221,6 @@ Summary: The Linux kernel
# only package docs noarch
%ifnarch noarch
%define with_doc 0
-%define with_firmware 0
%endif
# no need to build headers again for these arches,
@@ -231,6 +234,7 @@ Summary: The Linux kernel
%define with_up 0
%define with_headers 0
%define all_arch_configs kernel-%{version}-*.config
+%define with_firmware 1
+%define with_firmware %{?_without_firmware: 0} %{?!_without_firmware: 1}
%endif
# bootwrapper is only on ppc
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?
On Mon, Jul 07, 2008 at 11:37:10AM -0400, John W. Linville wrote: > So, here is what I propose: > > -- continue the current practice until 2.6.26 is released and the > 2.6.27 merge window closes; > > -- after that, continue the current practice for updating rawhide; but, > > -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits > to the -wireless.patch and do _not_ create a new -pending.patch for > 2.6.28 bits; > > -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will > get no more wireless updates at all; > > -- F10 will release with -wireless and -pending patches inherited from > rawhide, but they will "age out" following the process described for > F9/F8 above. Sorry to revive an old thread, but I'd like to amend the plan. I'm going to decline to add any post-2.6.27 wireless bits to rawhide. I think continuing that practice only complicates things for when rawhide becomes f10, and in the meantime just adds to my personal pain. Besides, I'm quite tired of...well, I'm just tired. I'm prepared to consider adding specific items as requested (e.g. ath9k), but for now let's just presume that rawhide will mostly just get its wireless bits through Linus. I still think that for continuity's sake f8 and f9 should continue to get wireless fixes from 2.6.27. Those should only be specific bug fixes (although I suppose there is still time for a new driver), so hopefully the nattering nabobs won't be opposed to continuing with that part of the original plan. Thanks, John -- John W. Linville [EMAIL PROTECTED] ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
