[opensuse-kernel] opensuse 11.0 kernel patch justification needed from you
Hi all, As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already. So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...) I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know. So, here goes, broken down by developer: Build system stuff that we need for building kernels patches.rpmify/buildhost patches.rpmify/cloneconfig.diff patches.rpmify/rpm-kernel-config Suse specific kernel markings: patches.suse/supported-flag patches.suse/suse-ppc64-branding (gotta love this one...) Xen stuff: 40+ patches. Yeah, we all know why they aren't upstream, oh well... Apparmor stuff: 48 patches JJ, any plan on getting these into mainline? I saw a posting a while ago with them to lkml, but they didn't go into -mm and I never saw any feedback, nor a repost. Jeff: reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25? reiserfs4 patches: patches.suse/reiser4-exports patches.suse/reiser4-sync_inodes why do we have these still as we don't have reiserfs4 and I don't think we plan on adding it, right? Or are they needed for a kmp? Is it still worth hanging on to this as upstream development is now dead? "kernel.org" patches: patches.kernel.org/gcc43-workaround.diff patches.kernel.org/ia64-jprobe-return-section-conflict.diff patches.kernel.org/ipmi-section-conflict.diff patches.kernel.org/powerpc-needs-uboot patches.kernel.org/psmouse-section-conflict.diff Are these going to be in 2.6.25? If not, why haven't we pushed them there? What about these others: patches.arch/s390-add-FREE_PTE_NR patches.fixes/ds1682-build-fix patches.fixes/libiscsi-missing-semicolon.diff patches.fixes/loop-barriers patches.fixes/loop-barriers2 patches.fixes/proc-scsi-scsi-fix.diff patches.suse/ext2-fsync-err patches.suse/ext3-barrier-default If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch patches.suse/dm-emulate-blkrrpart-ioctl Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch patches.fixes/pci-quirk-enable-smbus-on-hp-xw4100.patch Andi Kleen: Why aren't these upstream? patches.arch/disable-apic-error patches.arch/x86-nvidia-timer-quirk patches.suse/wireless-no-aes-select Olaf Hering: Why are we dragging these ppc patches around? Why aren't they upstream? Do we still care about the pegasos platform? Lots of these should be upstream already... patches.arch/ppc-efika-modalias.patch patches.arch/ppc-efika-mpc52xx-ac97.patch patches.arch/ppc-efika-psc-console-autodetection.patch patches.arch/ppc-iseries-remove-AVAILABLE_VETH.patch patches.arch/ppc-pegasos-console-autodetection.patch patches.arch/ppc-pegasos-mv643xx_eth-modalias.patch patches.arch/ppc-pegasos-pata_via-fixup.patch patches.arch/ppc-prom-nodisplay.patch patches.arch/ppc-vio-modalias.patch patches.arch/ppc64-xmon-dmesg-printing.patch patches.drivers/ppc64-adb patches.fixes/bootstrap-memoryless-node.patch patches.suse/nameif-track-rename.patch patches.suse/ppc-powerbook-usb-fn-key-default.patch Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800 patches.drivers/igb-2007-12-11 Hannes Reinecke Why aren't these upstream: patches.arch/s390-ccwgroup-attribute-ignore-newline patches.fixes/dm-mpath-hp-sw.patch patches.fixes/megaraid_mbox-dell-cerc-support patches.fixes/mptbase-vmware-fix Takashi Iwai: Are these going to be in 2.6.25?: patches.drivers/alsa-usb-exclude-1st-slot Greg Kroah-Hartman: Why aren't these upstream: patches.drivers/always-announce-new-usb-devices.patch patches.drivers/nozomi.patch patches.drivers/sysfs-crash-debugging.patch patches.suse/usb-storage-disable-delay.patch Bernhard Kaindl: Why are these patches not upstream: patches.drivers/early-firewire.diff Tejun Heo: Are these upstream for 2.6.25?: patches.drivers/libata-add-waits-for-govault patches.drivers/libata-force-cable-type patches.drivers/libata-sata_nv-disable-ADMA patches.drivers/libata-unlock-hpa-by-default patches.drivers/scsi-throttle-SG_DXFER_TO_FROM_DEV-warning-better Jiri Benc: Aren't these in 2.6.25? patches.fixes/mac80211-fix-hw-scan1.patch patches.fixes/mac80211-fix-hw-scan2.patch Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch Michael Schroeder: Why aren't we using the userspace bootsplash stuff that other distros do, and are still relying on an in-kernel jpg decoder? That seems pretty wasteful, and this code will never go upstream. Can't we change this now? patches.suse/bootsplash Andreas Gruenbacher: Your ACL stuff still isn't ready for upstream, right? How come only one patch is enabled in our tree? patches.suse/nfs4acl-ext3.diff Why aren't these upstream: patches.suse/parser-match_string.diff Kurt Garloff: Why isn't this one upstream? It's been in our tree for ages, which tends to make me think it's no longer needed for us? patches.suse/scsi-error-test-unit-ready-timeout We should be able to drop this now: patches.suse/setuid-dumpable-wrongdir Nick Piggin: If this is such a performance issue, why isn't it upstream? You would think that everyone would be wanting it, if it really is necessary... patches.suse/smtnice-disable Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind Andreas Schwab: Do we really care about this architecture enough to be dragging on all of these patches? As they aren't upstream, why do we care?: patches.suse/suse-ppc32-mol-BIT patches.suse/suse-ppc32-mol-get-property patches.suse/suse-ppc32-mol-handle-mm-fault patches.suse/suse-ppc32-mol-ioctl patches.suse/suse-ppc32-mol-kbuild.patch patches.suse/suse-ppc32-mol-sheep patches.suse/suse-ppc32-mol.patch Oliver Neukum: Is this still needed as we have disabled autosuspend automatically for usb devices: patches.suse/usb_printer_no_auto.diff KBD fun: These might go upstream, but I really doubt it. Note that kgdb hooks might be in mainline soon, so these might need to be majorly rewritten to handle these hooks. For now we'll keep them, but I really doubt their usability. Does anyone use this? patches.suse/kbd-ignore-gfx.patch patches.suse/kdb-common patches.suse/kdb-ia64 patches.suse/kdb-serial-8250 patches.suse/kdb-x86 squashfs fun: Someday this will make it upstream, but until then, we drag it along... patches.suse/squashfs.patch patches.suse/squashfs.patch.fixup No more maintainer, or no valid "Signed-off-by:" from a Novell developer: I'm going to drop these, unless someone really feels that they should be in our kernel tree. If so, please let me know by the end of the week. Maybe I should just throw them at lkml, as we are using them for some reason. If they don't stick, they should probably be gone... patches.fixes/bridge-module-get-put.patch patches.fixes/do_anonymous_page-race patches.fixes/grab-swap-token-oops patches.fixes/ieee1394-sbp2_long_sysfs_ieee1394_id.patch patches.fixes/ipv6-no-autoconf patches.fixes/oom-warning patches.fixes/parport-mutex patches.fixes/remount-no-shrink-dcache patches.fixes/seccomp-disable-tsc-option patches.fixes/tiocgdev patches.fixes/tulip-quad-NIC-ifdown patches.suse/connector-read-mostly patches.suse/crasher-26.diff patches.suse/filp-slab-rcu patches.suse/lockd-max-hosts-dynamic (and other lockd stuff, should all be dropped I feel, as we don't have anyone who cares about it anymore here...) patches.suse/netfilter-ipt_LOG-mac patches.suse/sysctl-add-affinity_load_balancing patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?) patches.suse/unmap_vmas-lat -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 5 Feb 2008, Greg KH wrote:
Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch
Hi Greg, these two are in Linus' tree (and randomize-brk is currently being heavily discussed :) ) already. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 11:19:19PM +0100, Jiri Kosina wrote:
On Tue, 5 Feb 2008, Greg KH wrote:
Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch
Hi Greg,
these two are in Linus' tree (and randomize-brk is currently being heavily discussed :) ) already.
Thanks for letting me know. Good luck with the discussions :) greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 02:19:32PM -0800, Greg KH wrote:
On Tue, Feb 05, 2008 at 11:19:19PM +0100, Jiri Kosina wrote:
On Tue, 5 Feb 2008, Greg KH wrote:
Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch
Hi Greg,
these two are in Linus' tree (and randomize-brk is currently being heavily discussed :) ) already.
Thanks for letting me know. Good luck with the discussions :)
Someone please just reinstall Pavels machine. ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 02:10:07PM -0800, Greg KH wrote:
Greg Kroah-Hartman: Why aren't these upstream: patches.drivers/always-announce-new-usb-devices.patch patches.drivers/nozomi.patch
These two are upstream for 2.6.25.
patches.drivers/sysfs-crash-debugging.patch
This one will never go there, but does live in -mm for people to help debug stuff with. I'm torn as to if it should ever go to mainline, as it seems to be less of a real problem these days. I'll probably just drop it soon.
patches.suse/usb-storage-disable-delay.patch
This is to make usb-storage devices show up faster on the desktop on request of a lot of people. Upstream wants to have a "safer" default, but as this seems to be working out well, I might just push this there... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
Hi all,
As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already.
So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...)
I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know.
reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25?
I doubt it. Probably 2.6.26 if I can get akpm to accept them into -mm for some testing. I've sent them to the reiserfs list several times with very little feedback. There's not a whole lot of interest in maintaining reiser3. I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHqOJ6LPWxlyuTD7IRAvfOAJ4s3QYAdZ5muYeHo1PWm0/8sHa3AwCeOcrj Y7m/WQbAxMdCSnmm91nqW+E= =AgOW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 05:26:03PM -0500, Jeff Mahoney wrote:
Greg KH wrote:
Hi all,
As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already.
So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...)
I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know.
reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25?
I doubt it. Probably 2.6.26 if I can get akpm to accept them into -mm for some testing. I've sent them to the reiserfs list several times with very little feedback. There's not a whole lot of interest in maintaining reiser3.
Just push them to him, if they are real bugfixes, they should go in.
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.
Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
On Tue, Feb 05, 2008 at 05:26:03PM -0500, Jeff Mahoney wrote:
Greg KH wrote:
Hi all,
As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already.
So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...)
I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know. reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25? I doubt it. Probably 2.6.26 if I can get akpm to accept them into -mm for some testing. I've sent them to the reiserfs list several times with very little feedback. There's not a whole lot of interest in maintaining reiser3.
Just push them to him, if they are real bugfixes, they should go in.
None of them are bug fixes. They're all enhancements to either behavior or code readability.
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.
Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
Yeah, actually. Anyone with reiserfs setup by YaST who hasn't disabled it is using it. The code works. That's not the problem. The problem is that it's the file i/o in kernel space blight that everyone rants about when they see it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHqOS3LPWxlyuTD7IRAje6AJ0SF074gTXJXvwYySWjotO7C9zP1wCgppMl DaE0gica0HzZJTub0O4JqLc= =o/sC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 05:35:36PM -0500, Jeff Mahoney wrote:
Greg KH wrote:
On Tue, Feb 05, 2008 at 05:26:03PM -0500, Jeff Mahoney wrote:
I doubt it. Probably 2.6.26 if I can get akpm to accept them into -mm for some testing. I've sent them to the reiserfs list several times with very little feedback. There's not a whole lot of interest in maintaining reiser3.
Just push them to him, if they are real bugfixes, they should go in.
None of them are bug fixes. They're all enhancements to either behavior or code readability.
Ah, ok, as long as you want to maintain them... :)
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.
Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
Yeah, actually. Anyone with reiserfs setup by YaST who hasn't disabled it is using it. The code works. That's not the problem. The problem is that it's the file i/o in kernel space blight that everyone rants about when they see it.
Ok, fair enough, thanks for letting me know. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Hi, On Tue, 5 Feb 2008, Greg KH wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.
Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Matz wrote:
Hi,
On Tue, 5 Feb 2008, Greg KH wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work.
I think I misunderstood Greg's question here. ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHqOXtLPWxlyuTD7IRAkH2AJ4mDNVc6e1mW2RY06/LjHOgcFVqQwCfapLY HGQd3mTybSGckzsii+TEzLI= =wPfK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Hi, On Tue, 5 Feb 2008, Jeff Mahoney wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work.
I think I misunderstood Greg's question here.
ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much.
I see. Well, as Greg has a point about the 7 years it probably makes sense to make the code suck as little as possible. I don't know upstreams "community" of reiser3, but perhaps they also would appreciate a little nicer code :-) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Matz wrote:
Hi,
On Tue, 5 Feb 2008, Jeff Mahoney wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :) I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work. I think I misunderstood Greg's question here.
ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much.
I see. Well, as Greg has a point about the 7 years it probably makes sense to make the code suck as little as possible. I don't know upstreams "community" of reiser3, but perhaps they also would appreciate a little nicer code :-)
It works out that "Upstream" is still the old Namesys guys, but I end up doing most of the work. When I do come up with something, they don't really comment on it. I might as well just merge these against -mm and let them stew for a revision before pushing them out to mainline. I'm confident in them, but it seems like every time I say that, it's the one time where things fall apart on me. ;) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHqOe4LPWxlyuTD7IRAnKtAKCce5QERCmm81omaS0sZdQQH2IazwCdFGHR Tj+o1ftqcWwBX4ngwGPMhtc= =U100 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue 2008-02-05 17:48:24, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Matz wrote:
Hi,
On Tue, 5 Feb 2008, Jeff Mahoney wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is. Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :) I don't see us deprecating reiser3. I don't know if the xattr patches are necessary for xattrs to work on reiser at all, but I do know that we use xattrs, so that too needs to continue to work. I think I misunderstood Greg's question here.
ReiserFS extended attributes have been in mainline since, oh, 2.6.14 or something. They're a fact. The patches are there to make the code not suck so much.
I see. Well, as Greg has a point about the 7 years it probably makes sense to make the code suck as little as possible. I don't know upstreams "community" of reiser3, but perhaps they also would appreciate a little nicer code :-)
It works out that "Upstream" is still the old Namesys guys, but I end up doing most of the work. When I do come up with something, they don't really comment on it. I might as well just merge these against -mm and let them stew for a revision before pushing them out to mainline. I'm
That sounds like a way to go. You can also make yourself maintainer of reiser... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pavel Machek wrote:
On Tue 2008-02-05 17:48:24, Jeff Mahoney wrote:
It works out that "Upstream" is still the old Namesys guys, but I end up doing most of the work. When I do come up with something, they don't really comment on it. I might as well just merge these against -mm and let them stew for a revision before pushing them out to mainline. I'm
That sounds like a way to go. You can also make yourself maintainer of reiser...
I get CC'd on reiserfs patches as it is, but I'm not sure an official maintainership is a pile I want to step in. :) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHrIGGLPWxlyuTD7IRAhtkAJ9Teb0rzXLaUHX3TzHZ1/6kSZ6gnACbBrc8 hmTJtUvGM/Np3OON7WWvgZQ= =nQor -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 11:37:43PM +0100, Michael Matz wrote:
Hi,
On Tue, 5 Feb 2008, Greg KH wrote:
I also imagine that bringing up the reiser3 xattr code will be like a third rail, but it is what it is.
Do we have people that rely on it in our kernels? Do we want to drag it along for 7 more years? :)
I don't see us deprecating reiser3.
I don't want to do that, just curious as to if we are having people rely on the xattrs stuff. Jeff says that we are, so that's good enough for me :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:
Jiri Benc: Aren't these in 2.6.25? patches.fixes/mac80211-fix-hw-scan1.patch patches.fixes/mac80211-fix-hw-scan2.patch
They are. Thanks, Jiri -- Jiri Benc SUSE Labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 11:31:31PM +0100, Jiri Benc wrote:
On Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:
Jiri Benc: Aren't these in 2.6.25? patches.fixes/mac80211-fix-hw-scan1.patch patches.fixes/mac80211-fix-hw-scan2.patch
They are.
Nice, thanks for letting me know. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, Feb 05, 2008 at 02:10:07PM -0800, Greg KH wrote:
No more maintainer, or no valid "Signed-off-by:" from a Novell developer: I'm going to drop these, unless someone really feels that they should be in our kernel tree. If so, please let me know by the end of the week. Maybe I should just throw them at lkml, as we are using them for some reason. If they don't stick, they should probably be gone... patches.suse/lockd-max-hosts-dynamic (and other lockd stuff, should all be dropped I feel, as we don't have anyone who cares about it anymore here...)
I've now deleted this one, and the other commented out lockd ones. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Greg KH <gregkh@suse.de> [2008-02-05 23:10]:
Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800
It was a temporary binutils workaround, it was from a mailing list posting. So it didn't make sense to submit upstream because if it would, the Author had done already. I'll test if the patch is needed at all ...
patches.drivers/igb-2007-12-11
The IGB network driver. Intel started already 2 submissions for that driver and still tries to work with the netdev maintainer to get the driver accepted. However, we need the driver internally to test several machines, and KMPs are not an option since we need the network device during installation. Since SP2 and SP4 have the driver it's bad for us if we cannot install the latest kernel release on the latest hardware, and therefore, please keep the driver until it's mainline. It doesn't touch any other files in the kernel tree. Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 08:05:52AM +0100, Bernhard Walle wrote:
* Greg KH <gregkh@suse.de> [2008-02-05 23:10]:
Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800
It was a temporary binutils workaround, it was from a mailing list posting. So it didn't make sense to submit upstream because if it would, the Author had done already. I'll test if the patch is needed at all ...
Thanks, feel free to drop it if it's not needed :)
patches.drivers/igb-2007-12-11
The IGB network driver. Intel started already 2 submissions for that driver and still tries to work with the netdev maintainer to get the driver accepted. However, we need the driver internally to test several machines, and KMPs are not an option since we need the network device during installation. Since SP2 and SP4 have the driver it's bad for us if we cannot install the latest kernel release on the latest hardware, and therefore, please keep the driver until it's mainline. It doesn't touch any other files in the kernel tree.
Ugh, that driver, I forgot about that. Fine, no objection from me to keeping it there, as long as we update it. There should be a new version out soon, right? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Greg KH <gregkh@suse.de> [2008-02-08 05:22]:
On Wed, Feb 06, 2008 at 08:05:52AM +0100, Bernhard Walle wrote:
* Greg KH <gregkh@suse.de> [2008-02-05 23:10]:
Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800
It was a temporary binutils workaround, it was from a mailing list posting. So it didn't make sense to submit upstream because if it would, the Author had done already. I'll test if the patch is needed at all ...
Thanks, feel free to drop it if it's not needed :)
Ok, build is running.
Ugh, that driver, I forgot about that. Fine, no objection from me to keeping it there, as long as we update it. There should be a new version out soon, right?
Yes, I'll update to the latest version from e1000.sf.net. I also recognised that it's mainline now since 2 weeks: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
At Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:
Takashi Iwai: Are these going to be in 2.6.25?: patches.drivers/alsa-usb-exclude-1st-slot
This isn't needed for 2.6.25 because a newer (better) way of device assignment was introduced. So, it can be removed when we upgrade to 2.6.25. It's harmless to keep this, though. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 08:13:34AM +0100, Takashi Iwai wrote:
At Tue, 5 Feb 2008 14:10:07 -0800, Greg KH wrote:
Takashi Iwai: Are these going to be in 2.6.25?: patches.drivers/alsa-usb-exclude-1st-slot
This isn't needed for 2.6.25 because a newer (better) way of device assignment was introduced. So, it can be removed when we upgrade to 2.6.25. It's harmless to keep this, though.
Ok, we'll probably move to 2.6.25-rc1 to start on the testing cycle when it comes out, so I'll try to remember to remove this then. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
* Greg KH <gregkh@suse.de> [2008-02-05 23:10]:
patches.suse/crasher-26.diff
Please not, I use that sometimes for testing kdump. :) I can offer to "maintain" that module (I doubt we get L3 bugs about this :-)), and maybe also try to submit upstream if they like such code. Bernhard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 08:14:33AM +0100, Bernhard Walle wrote:
* Greg KH <gregkh@suse.de> [2008-02-05 23:10]:
patches.suse/crasher-26.diff
Please not, I use that sometimes for testing kdump. :) I can offer to "maintain" that module (I doubt we get L3 bugs about this :-)), and maybe also try to submit upstream if they like such code.
Yes, I think this should go upstream, I'll work on that. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Greg KH wrote:
Hi all,
[ .. ]
patches.fixes/libiscsi-missing-semicolon.diff Should be fixed upstream by now.
patches.fixes/loop-barriers patches.fixes/loop-barriers2 patches.fixes/proc-scsi-scsi-fix.diff
This is a fix for /proc/scsi/scsi for large number of devices. hch didn't accept this a it fixes an obsolete interface.
Hannes Reinecke Why aren't these upstream: patches.arch/s390-ccwgroup-attribute-ignore-newline They promised me it would; I'll have to resend it.
patches.fixes/dm-mpath-hp-sw.patch
Already is.
patches.fixes/megaraid_mbox-dell-cerc-support
It's Megaraid. 'They will look into it'.
patches.fixes/mptbase-vmware-fix
Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 08:38:18AM +0100, Hannes Reinecke wrote:
Greg KH wrote:
Hi all,
[ .. ]
patches.fixes/libiscsi-missing-semicolon.diff Should be fixed upstream by now.
ok.
patches.fixes/loop-barriers patches.fixes/loop-barriers2 patches.fixes/proc-scsi-scsi-fix.diff
This is a fix for /proc/scsi/scsi for large number of devices. hch didn't accept this a it fixes an obsolete interface.
Yeah, I remember that. What about the loop patches?
Hannes Reinecke Why aren't these upstream: patches.arch/s390-ccwgroup-attribute-ignore-newline They promised me it would; I'll have to resend it.
Please do.
patches.fixes/dm-mpath-hp-sw.patch
Already is.
patches.fixes/megaraid_mbox-dell-cerc-support
It's Megaraid. 'They will look into it'.
Yeah right :)
patches.fixes/mptbase-vmware-fix
Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it.
Do we still support older vmware installs? I didn't think we did, especially as they need to upgrade their kernel modules with our kernel releases. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Greg KH wrote:
On Wed, Feb 06, 2008 at 08:38:18AM +0100, Hannes Reinecke wrote: [ .. ]
patches.fixes/mptbase-vmware-fix
Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it.
Do we still support older vmware installs? I didn't think we did, especially as they need to upgrade their kernel modules with our kernel releases.
This is nothing to do with the kernel modules, this is the VMWare emulation layer. So they will have to update their VMWare installation itself if we drop this fix. Hmm. We should verify that it is indeed fixed by later versions. And which version that is, so that we can point to the correct version. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Fri, Feb 08, 2008 at 08:10:39AM +0100, Hannes Reinecke wrote:
Greg KH wrote:
On Wed, Feb 06, 2008 at 08:38:18AM +0100, Hannes Reinecke wrote: [ .. ]
patches.fixes/mptbase-vmware-fix
Workaround for broken VMWare emulation. Vetoed upstream as VMWare should fix their emulation. Which they did in later versions. However, older VMWare installation still require it.
Do we still support older vmware installs? I didn't think we did, especially as they need to upgrade their kernel modules with our kernel releases.
This is nothing to do with the kernel modules, this is the VMWare emulation layer. So they will have to update their VMWare installation itself if we drop this fix.
Hmm. We should verify that it is indeed fixed by later versions. And which version that is, so that we can point to the correct version.
Ok, I'm going to drop this as no other distro has this patch and vmware seems to work well with them :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind
The code was in mainline for a couple of releases and the kicked out again for philosophical (I would call it) reasons. Andi and I are in agreement that it should be re-submitted to mainline at some point, but we clearly need to make sure the time (and the code) is right for a second try.
patches.suse/crasher-26.diff
Please keep this one for debugging purposes. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wednesday 06 February 2008 08:46:14 Jan Beulich wrote:
Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind
The code was in mainline for a couple of releases and the kicked out again for philosophical (I would call it) reasons. Andi and I are in agreement that it should be re-submitted to mainline at some point, but we clearly need to make sure the time (and the code) is right for a second try.
Yes, the idea was to get it even more testing and then eventually resubmit. Also it's a very valuable feature that is definitely worth carrying even out of tree -- reliable backtraces make it much easier to look at oopses. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 07:46:14AM +0000, Jan Beulich wrote:
Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind
The code was in mainline for a couple of releases and the kicked out again for philosophical (I would call it) reasons. Andi and I are in agreement that it should be re-submitted to mainline at some point, but we clearly need to make sure the time (and the code) is right for a second try.
Ah, I remember that.
patches.suse/crasher-26.diff
Please keep this one for debugging purposes.
Will do. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tuesday 05 February 2008 23:10:07 Greg KH wrote:
If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger
There is a change being worked on upstream (or rather mm) to do this more generically.
Andi Kleen: Why aren't these upstream? patches.arch/disable-apic-error
The idea was that we should find out upstream why the APIC error occurs and so not silence it, but don't do that for the distro production kernels.
patches.arch/x86-nvidia-timer-quirk
Hmm, I thought I had submitted that one but it seems to have gotten lost somewhere.
patches.suse/wireless-no-aes-select
I submitted that one. The maintainers thought it was not needed, but I'm still not convinced. Right now modprobe aes without this patch still does load the wrong code I think.
Bernhard Kaindl: Why are these patches not upstream: patches.drivers/early-firewire.diff
They are. Did you not check mainline?
KBD fun:
KDB
These might go upstream, but I really doubt it. Note that kgdb hooks might be in mainline soon,
No, the basic hooks have been in forever. kgdb adds a few new one, but most of them are actually misguided and KDB typically doesn't need them.
so these might need to be majorly rewritten to handle these hooks. For now we'll keep them, but I really doubt their usability. Does anyone use this?
It is the current standard kernel debugger for SUSE and afaik used by a lot of people.
patches.fixes/ipv6-no-autoconf
Might be still needed for Xen
patches.fixes/oom-warning
This patch seems valuable to me.
patches.fixes/tiocgdev
This is needed for init. There is unfortunately some philosophical disagreement on that one for mainline (I tried to submit it a long time ago). Maintainer is Werner Fink. Probably would make sense to resubmit it -- i'm a little tired of always seeing the "kernel does not support TIOCGDEV" messages when I boot a mainline kernel.
patches.suse/crasher-26.diff
This one is a valuable debugging tool and should be probably submitted.
patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?)
No we can't because that would break updates with encrypted file systems. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 09:42:22AM +0100, Andi Kleen wrote:
On Tuesday 05 February 2008 23:10:07 Greg KH wrote:
If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger
There is a change being worked on upstream (or rather mm) to do this more generically.
Ok, will we know when those changes get merged so we no longer have to take this patch?
Andi Kleen: Why aren't these upstream? patches.arch/disable-apic-error
The idea was that we should find out upstream why the APIC error occurs and so not silence it, but don't do that for the distro production kernels.
Ok.
patches.arch/x86-nvidia-timer-quirk
Hmm, I thought I had submitted that one but it seems to have gotten lost somewhere.
patches.suse/wireless-no-aes-select
I submitted that one. The maintainers thought it was not needed, but I'm still not convinced. Right now modprobe aes without this patch still does load the wrong code I think.
Try poking them again if you get the chance.
Bernhard Kaindl: Why are these patches not upstream: patches.drivers/early-firewire.diff
They are. Did you not check mainline?
Not yet, I hadn't. I see that there now.
KBD fun:
KDB
These might go upstream, but I really doubt it. Note that kgdb hooks might be in mainline soon,
No, the basic hooks have been in forever. kgdb adds a few new one, but most of them are actually misguided and KDB typically doesn't need them.
so these might need to be majorly rewritten to handle these hooks. For now we'll keep them, but I really doubt their usability. Does anyone use this?
It is the current standard kernel debugger for SUSE and afaik used by a lot of people.
Ok, just wanted to make sure.
patches.fixes/ipv6-no-autoconf
Might be still needed for Xen
Ok, will move over to Xen directory then.
patches.fixes/oom-warning
This patch seems valuable to me.
Yeah, should save us on support calls.
patches.fixes/tiocgdev
This is needed for init. There is unfortunately some philosophical disagreement on that one for mainline (I tried to submit it a long time ago). Maintainer is Werner Fink.
Probably would make sense to resubmit it -- i'm a little tired of always seeing the "kernel does not support TIOCGDEV" messages when I boot a mainline kernel.
I'll try to push it.
patches.suse/crasher-26.diff
This one is a valuable debugging tool and should be probably submitted.
patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?)
No we can't because that would break updates with encrypted file systems.
But there already is a twofish crypto module in the upstream kernel. Why are we adding another one? Shouldn't we use the one already there? If there are problems with the upstream one, we should fix it, not just drag in another new implementation. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Friday 08 February 2008 05:31:48 Greg KH wrote:
On Wed, Feb 06, 2008 at 09:42:22AM +0100, Andi Kleen wrote:
On Tuesday 05 February 2008 23:10:07 Greg KH wrote:
If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger
There is a change being worked on upstream (or rather mm) to do this more generically.
Ok, will we know when those changes get merged so we no longer have to take this patch?
Either .25 (I think it was already in -mm so it might be a late merge) or .26 I guess.
patches.fixes/tiocgdev
This is needed for init. There is unfortunately some philosophical disagreement on that one for mainline (I tried to submit it a long time ago). Maintainer is Werner Fink.
Probably would make sense to resubmit it -- i'm a little tired of always seeing the "kernel does not support TIOCGDEV" messages when I boot a mainline kernel.
I'll try to push it.
The problem was iirc Al Viro not happy about a dev_t being passed around. But we can probably argue it is a legacy interface by now (it has been in SUSE kernels for many many years)
patches.suse/crasher-26.diff
This one is a valuable debugging tool and should be probably submitted.
patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?)
No we can't because that would break updates with encrypted file systems.
But there already is a twofish crypto module in the upstream kernel. Why are we adding another one?
They are not compatible on disk.
Shouldn't we use the one already there? If there are problems with the upstream one, we should fix it, not just drag in another new implementation.
The two modules just adapt cryptoloop to twofish, but do it in different ways. I'm not sure it would make that much sense to merge them. I guess it would make sense to submit this one upstream though. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 2008-02-05 at 14:10 -0800, Greg KH wrote:
Hi all,
Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch
Everything should be mainline (or soon, in 2.6.25-rcX, even the dsdt override patch...) except this one: patches.fixes/acpi_force-fan-active.patch I will have a look at this one. This one slipped on my list, but it's Hannes patch:
patches.suse/dm-emulate-blkrrpart-ioctl
Thanks, Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 10:50:02AM +0100, Thomas Renninger wrote:
On Tue, 2008-02-05 at 14:10 -0800, Greg KH wrote:
Hi all,
Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch
Everything should be mainline (or soon, in 2.6.25-rcX, even the dsdt override patch...) except this one: patches.fixes/acpi_force-fan-active.patch
I will have a look at this one.
Thanks. And congrats on the dsdt patch :)
This one slipped on my list, but it's Hannes patch:
patches.suse/dm-emulate-blkrrpart-ioctl
Hannes, any thoughts? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Greg KH wrote:
On Wed, Feb 06, 2008 at 10:50:02AM +0100, Thomas Renninger wrote:
Hi all, Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch Everything should be mainline (or soon, in 2.6.25-rcX, even the dsdt override patch...) except this one:
On Tue, 2008-02-05 at 14:10 -0800, Greg KH wrote: patches.fixes/acpi_force-fan-active.patch
I will have a look at this one.
Thanks. And congrats on the dsdt patch :)
This one slipped on my list, but it's Hannes patch:
patches.suse/dm-emulate-blkrrpart-ioctl
Hannes, any thoughts?
I'll post it on the device-mapper list. Let's see what the response is. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue 05-02-08 14:10:07, Greg KH wrote:
No more maintainer, or no valid "Signed-off-by:" from a Novell developer: I'm going to drop these, unless someone really feels that they should be in our kernel tree. If so, please let me know by the end of the week. Maybe I should just throw them at lkml, as we are using them for some reason. If they don't stick, they should probably be gone... patches.fixes/bridge-module-get-put.patch patches.fixes/do_anonymous_page-race Maybe worth submitting but I'd think it's not really needed because when we submit bio we should have pages/buffers locked and unlocking is a barrier if I'm right.
patches.fixes/grab-swap-token-oops patches.fixes/ieee1394-sbp2_long_sysfs_ieee1394_id.patch patches.fixes/ipv6-no-autoconf patches.fixes/oom-warning patches.fixes/parport-mutex patches.fixes/remount-no-shrink-dcache
Hmm, this is just a hack to hide latency problem in shrink_dcache_sb(). I'm not sure if mainline still has the problem. If it still has it, we should fix it differently (check for lock contention and drop the lock if there is some).
patches.fixes/seccomp-disable-tsc-option patches.fixes/tiocgdev patches.fixes/tulip-quad-NIC-ifdown patches.suse/connector-read-mostly patches.suse/crasher-26.diff patches.suse/filp-slab-rcu patches.suse/lockd-max-hosts-dynamic (and other lockd stuff, should all be dropped I feel, as we don't have anyone who cares about it anymore here...) patches.suse/netfilter-ipt_LOG-mac patches.suse/sysctl-add-affinity_load_balancing patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?) patches.suse/unmap_vmas-lat
Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 02:55:59PM +0100, Jan Kara wrote:
On Tue 05-02-08 14:10:07, Greg KH wrote:
No more maintainer, or no valid "Signed-off-by:" from a Novell developer: I'm going to drop these, unless someone really feels that they should be in our kernel tree. If so, please let me know by the end of the week. Maybe I should just throw them at lkml, as we are using them for some reason. If they don't stick, they should probably be gone... patches.fixes/bridge-module-get-put.patch patches.fixes/do_anonymous_page-race Maybe worth submitting but I'd think it's not really needed because when we submit bio we should have pages/buffers locked and unlocking is a barrier if I'm right.
So we should drop it?
patches.fixes/grab-swap-token-oops patches.fixes/ieee1394-sbp2_long_sysfs_ieee1394_id.patch patches.fixes/ipv6-no-autoconf patches.fixes/oom-warning patches.fixes/parport-mutex patches.fixes/remount-no-shrink-dcache
Hmm, this is just a hack to hide latency problem in shrink_dcache_sb(). I'm not sure if mainline still has the problem. If it still has it, we should fix it differently (check for lock contention and drop the lock if there is some).
So we should drop it? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
patches.fixes/bridge-module-get-put.patch
I just realized this one's mine, too (it does say so in the header) - it was NAKed upstream as the bridge maintainer thinks that (explicit) unloading the bridge module should have the effect of bringing down all bridges. It was agreed upon, though, that implicit unloading of the bridge module should be prevented by some (supposedly being thought of but not yet implemented mechanism). Since we have no better way to fix the underlying bug, I'd suggest keeping the patch. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
patches.fixes/ipv6-no-autoconf
This is a workaround for a XEN problem (same MAC address assigned to multiple bridged virtual interfaces). It had been discussed on netdev and rejected: http://www.mail-archive.com/netdev@vger.kernel.org/msg20888.html There is a bug in the XEN bugzilla about this issue ( http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 ), which does not solve the problem either. I think this patch should just be considered part of the XEN mess ;-) -- Jiri Bohac <jbohac@suse.cz> SUSE Labs, SUSE CZ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 03:24:26PM +0100, Jiri Bohac wrote:
patches.fixes/ipv6-no-autoconf
This is a workaround for a XEN problem (same MAC address assigned to multiple bridged virtual interfaces). It had been discussed on netdev and rejected: http://www.mail-archive.com/netdev@vger.kernel.org/msg20888.html
There is a bug in the XEN bugzilla about this issue ( http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 ), which does not solve the problem either.
I think this patch should just be considered part of the XEN mess ;-)
Ok, I'll move it there. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le mardi 05 février 2008, Greg KH a écrit :
Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)
Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.
patches.fixes/pci-quirk-enable-smbus-on-hp-xw4100.patch
Already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=... -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Feb 06, 2008 at 05:38:33PM +0100, Jean Delvare wrote:
Le mardi 05 f?vrier 2008, Greg KH a ?crit?:
Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)
Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.
It sounds like they are there, so can you try to get them in before the merge window closes?
patches.fixes/pci-quirk-enable-smbus-on-hp-xw4100.patch
Already upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
Great, thanks for the link. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le vendredi 08 février 2008, Greg KH a écrit :
On Wed, Feb 06, 2008 at 05:38:33PM +0100, Jean Delvare wrote:
Le mardi 05 f?vrier 2008, Greg KH a ?crit?:
Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)
Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.
It sounds like they are there, so can you try to get them in before the merge window closes?
Linus didn't like them, so they are unlikely to make it into 2.6.25. Discussions are going on with regards to how this feature should be implemented. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, 2008-02-21 at 16:12 +0100, Jean Delvare wrote:
Le vendredi 08 février 2008, Greg KH a écrit :
On Wed, Feb 06, 2008 at 05:38:33PM +0100, Jean Delvare wrote:
Le mardi 05 f?vrier 2008, Greg KH a ?crit?:
Thomas Renninger: How come these aren't upstream: (...) patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch (...)
Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch
These two depend on Thomas' ACPI patches above. I'll look into pushing them upstream once the ACPI patches in question are there.
It sounds like they are there, so can you try to get them in before the merge window closes?
Linus didn't like them, so they are unlikely to make it into 2.6.25. Discussions are going on with regards to how this feature should be implemented.
I'd vote to keep them for a while and remove them at late Beta 11.0 stage or simply disable the messages by setting default param to be quiet (->might help to solve an ugly bug later by enabling and report possible interference via boot param in a related bug report). Hopefully we get some reports via bugzilla.novell.com and can report them and discuss it upstream then. Like that we might get a clearer picture about possible interference on specific BIOSes without polluting the mainline kernel with a temporary debug patch. What do you think? Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Le mercredi 27 février 2008, Thomas Renninger a écrit :
On Thu, 2008-02-21 at 16:12 +0100, Jean Delvare wrote:
Le mardi 05 février 2008, Greg KH a écrit :
Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch (...)
Linus didn't like them, so they are unlikely to make it into 2.6.25. Discussions are going on with regards to how this feature should be implemented.
I'd vote to keep them for a while and remove them at late Beta 11.0 stage or simply disable the messages by setting default param to be quiet (->might help to solve an ugly bug later by enabling and report possible interference via boot param in a related bug report).
Hopefully we get some reports via bugzilla.novell.com and can report them and discuss it upstream then.
Like that we might get a clearer picture about possible interference on specific BIOSes without polluting the mainline kernel with a temporary debug patch.
What do you think?
I would keep the patches in openSuse 11.0, if Greg is OK with that. I agree that it will help with support. I would even let the setting to "lax", it's not like the log message is really frightening, and this will save one round-trip in bugzilla. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Dienstag 05 Februar 2008 23:10:07, you (Greg KH) wrote:
Greg Kroah-Hartman: Why aren't these upstream: ... patches.drivers/nozomi.patch
It's upstream now, so i updated the patch accordingly. Thanks, Frank -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (17)
-
Andi Kleen -
Bernhard Walle -
Frank Seidel -
Greg KH -
Hannes Reinecke -
Jan Beulich -
Jan Kara -
Jean Delvare -
Jeff Mahoney -
Jiri Benc -
Jiri Bohac -
Jiri Kosina -
Marcus Meissner -
Michael Matz -
Pavel Machek -
Takashi Iwai -
Thomas Renninger