Re: Classification scheme for 2.6 kernel patches
On Tue, Jan 11, 2005 at 10:25:37AM +0100, Florian Weimer wrote: * Marc Haber: On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: Cherrypicking makes little sense, because there are only cherries. :-) For my systems, I care about security holes being fixed, but I do not care about some obscure video hardware, or additional features. So Cherry is relative. Fix upstream's security process, Broken beyond repair, IMO. or use vendor kernels. Which is what I am trying to do. Debian is a vendor. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Classification scheme for 2.6 kernel patches
Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. cleanup: Cosmetic change bugfix: Fixes a bug that might result in errant behavior crashfix: Fixes a bug that might result in a kernel crash oopsfix: Fixes a bug that might result in a kernel oops build: Fixes a build time issue feature: Adds a new feature maybe-security: Fixes an issue that might pose a security problem security: Fixes a sure security problem license: Patch accompanying driver removal due to license issues documentation: Documentation patch only patchfix: fixes a bug introduced by some other patch Architecture-specific tags do not seem to be necessary as architecture specific patches have the architecture in their file name. To locate possible problems with the classification, I have tried to roughly classify the patches from current 2.6.10 svn: x86-i486_emu.dpatch feature tty-locking-fixes9.dpatch bugfix sparc64-hme-lockup.dpatch bugfix sparc32-initrd-memcpy.dpatchbugfix smbfs-overflow-fixes.dpatch maybe-security smbfs-overflow-fixes-2.dpatch maybe-security sec_brk-locked.dpatch security remove-references-to-removed-drivers.dpatch license powerpc-serial.dpatch bugfix powerpc-pegasos-via82cxxx.dpatchbugfix powerpc-pegasos-2.dpatchfeature powerpc-g4-l2-flush-errata.dpatch bugfix modular-vesafb.dpatch feature modular-vesafb-2.dpatch feature modular-ide.dpatch bugfix modular-ide-pnp.dpatch feature modular-ide-2.dpatchfeature marvell-pegasos.dpatch feature ia64-irq-affinity-upfix.dpatch build ia64-generic-no-smp.dpatch build ia64-generic-no-smp-1-to-2.dpatch build ia64-bte_error-missing-include.dpatch build fs-asfs.dpatch feature fix-mxser-compile.dpatchbuild drm-locking-fixes.dpatchcrashfix drivers-scsi_changer.dpatch feature drivers-net-tg3-readd.dpatchlicense drivers-net-8139too-locking.dpatch crashfix drivers-input-psaux-hacks.dpatchfeature drivers-ide-dma-blacklist-toshiba.dpatchbugfix drivers-ide-__devinit.dpatchcleanup doc-post_halloween.dpatch documentation alsa-module-load-fix.dpatch crashfix 032-do_brk_security_fixes.dpatchsecurity 031-sg_scsi_ioctl_int_overflows.dpatch security 030-moxa_user_copy_checking.dpatch security 029-random_poolsize_overflow.dpatch security 028-do_brk_security_fixes.dpatchsecurity 027-track_dummy_capability-2.dpatch cleanup 026-nfs_o_direct_error.dpatch maybe-security 025-track_dummy_capability.dpatch maybe-security 024-nfs_incorrect_df_output.dpatch bugfix 023-nfs_dentry_refcount.dpatch bugfix 022-sunrpc_xdr_flush_pages.dpatch bugfix 021-sunrpc_check_before_kill.dpatch bugfix 020-clear_cyrix_mii_ecx_reg.dpatch bugfix 019-conntrack_tcp_RST_handling.dpatch bugfix 018-ipt_recent_proc_remove.dpatch bugfix 017-conntrack_sctp_sysctl.dpatchbugfix 016-cs461x_gameport.dpatch feature 015-vmscan_total_scanned.dpatch bugfix 014-acpi_video_dev_slab_corruption.dpatch maybe-security 013-conntrack_standalone_sysctl.dpatch bugfix 012-conntrack_standalone_proc_removal.dpatchbugfix 011-parport_pc_module_parm_mixing.dpatchcleanup 010-sparc64_macro_pmd_offset.dpatch cleanup 009-ipt_ecn_corrupt_chksum.dpatch bugfix 008-sock_without_ipv6.dpatchbuild 007-pci_ide_no_reserve.dpatch bugfix 006-zatm_cast_fix_fix.dpatchbuild 005-sparc64_no_i_sock-2.dpatch patchfix 004-sparc64_no_i_sock.dpatchbuild 003-libata_alpha_build_fix.dpatch build 002-pio_err_handling.dpatch bugfix 001-acpi_ibm_exit.dpatchcleanup One possible source of problems is that some patches, for example the patchfix patches, depend on some other patches. In those case, that dependency needs to be documented more clearly. Additionally, maybe the bugfix category needs to be split into more categories, we have too
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. [snip] I would like to solicit your comments about this concept. I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Thiemo
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. I think only one of my machines is running a Debian-built kernel. Debian is much more forgiving of using a stock kernel than some other distributions. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 07:36:47PM +, Matthew Wilcox wrote: On Sun, Jan 09, 2005 at 08:33:51PM +0100, Marc Haber wrote: Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. It is adviseable to take a snapshot from the Debian kernel svn? And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. I think only one of my machines is running a Debian-built kernel. Debian is much more forgiving of using a stock kernel than some other distributions. It definetely is, and it is exceptionally good in allowing usage of infrastructure for local builds and installation as well. kernel-package is one of the big advantages that has driven me to Debian years ago. Using infrastructure that makes individual patch files is a big step forward as well as this enables people to individually choose their patch sets. The progress is impressive. What we need now are better docs, and a few minor tweaks in the tools. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: On Sun, Jan 09, 2005 at 07:40:06PM +0100, Thiemo Seufer wrote: I think the effort to do so is better invested elsewhere. As a general rule, the kernel team strives to keep the debian-specific patches to a minimum. For people without in-depth kernel knowledge it's probably best to take the full set of patches and add their own (feature- ?) patches on top. Actually, the kernel of my dreams is more near to the vanilla kernel.org kernel, so I'd like to be able to throw out patches that you need to apply because of your _much_ broader user base. Well, then you need detailed knowledge about those patches in any case. (If you know you don't use that code, why bother? The patch won't make a difference for you.) otoh, I would like to run a 2.6.10 kernel _now_ and cannot take the distribution kernel because it is still stuck in NEW. http://www.acm.rpi.edu/~dilinger/ It is adviseable to take a snapshot from the Debian kernel svn? You can use the appopriate SVN tag as well if you like. And, without trolling, I'd like to build my local kernels from sources that haven't had drivers removed because of non-free licenses. Disable the purge script in the kernel-source source package. Thiemo
Re: Classification scheme for 2.6 kernel patches
Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? It generates work. The time is better used for pushing those patches upstream. Cherrypicking makes little sense, because there are only cherries. :-) Thiemo
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 08:52:59PM +0100, Thiemo Seufer wrote: Cherrypicking makes little sense, because there are only cherries. :-) For my systems, I care about security holes being fixed, but I do not care about some obscure video hardware, or additional features. So Cherry is relative. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc A large problem with this is that patches in our -source packages assume a certain order. A patch may depend upon another patch; removing one breaks the other. We have this problem when cherry-picking changes from bitkeeper; I'd imagine it gets even worse when you attempt to pick changes from -source packages.
Re: Classification scheme for 2.6 kernel patches
On Sun, Jan 09, 2005 at 03:56:48PM -0500, Andres Salomon wrote: On Sun, 09 Jan 2005 20:41:41 +0100, Marc Haber wrote: On Sun, Jan 09, 2005 at 08:25:33PM +0100, Christoph Hellwig wrote: Agreed. The package is not a repository for cherrypicking patches but intended to used as a whole thing. I am pretty disappointed about that attitude towards your users. What exactly is the problem with a little more docs to _allow_ cherrypicking? Greetings Marc A large problem with this is that patches in our -source packages assume a certain order. A patch may depend upon another patch; removing one breaks the other. We have this problem when cherry-picking changes from bitkeeper; I'd imagine it gets even worse when you attempt to pick changes from -source packages. Choosing a working patchset would be the responsibility of the picking user, no work on your side involved. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Re: Classification scheme for 2.6 kernel patches
On Sun, 09 Jan 2005 19:01:38 +0100, Marc Haber wrote: Hi, A few months ago, I asked on this list for more informative description of patches enabling non-kernel hackers to choose individual patchsets for their local kernels. Unfortunately, that question was denied pretty fast. Looks like you guys don't have time to write more extensive docs. cleanup: Cosmetic change Shouldn't be in Debian kernels. bugfix: Fixes a bug that might result in errant behavior This applies to pretty much every patch. Even feature additions are usually fixing bugs of the type machine XYZ doesn't boot! or I can't use my network card with your kernel crashfix: Fixes a bug that might result in a kernel crash oopsfix: Fixes a bug that might result in a kernel oops build: Fixes a build time issue Not worth classifying the differences, imo. Something that might crash one machine might oops on another; it depends on hardware, what the kernel config is, etc. Build problems are the most clear-cut on this list, but I can't imagine why you wouldn't want to include them. There's also warning build fixes, which might be necessary (if the code in question causes an oops/crash), or might simply be to shut the compiler up. feature: Adds a new feature Aside from non-x86 stuff, we try to avoid these. Some archs need them for basic hardware; in which case, they could easily be considered a bugfix. The general rule is, if it's not needed to boot/install, it should be in a separate kernel-patch package. maybe-security: Fixes an issue that might pose a security problem Pretty much any bugfix is possibly a security hole that no one's figured out how to exploit yet. This is just another name for bugfix. security: Fixes a sure security problem We already try to use this one. license: Patch accompanying driver removal due to license issues I believe we have exactly 1 patch (tg3-readd) that would be classified as this. That patch needs to go away, as well, as it's a hassle to maintain. documentation: Documentation patch only I would think this would be easy enough to determine simply by looking at the patch? We don't really have too many of these to begin with. patchfix: fixes a bug introduced by some other patch When you end up with a large number of patches, this becomes quite an annoyance. Architecture-specific tags do not seem to be necessary as architecture specific patches have the architecture in their file name. To locate possible problems with the classification, I have tried to roughly classify the patches from current 2.6.10 svn: x86-i486_emu.dpatch feature tty-locking-fixes9.dpatch bugfix sparc64-hme-lockup.dpatch bugfix sparc32-initrd-memcpy.dpatch bugfix smbfs-overflow-fixes.dpatch maybe-security smbfs-overflow-fixes-2.dpatch maybe-security sec_brk-locked.dpatch security remove-references-to-removed-drivers.dpatch license powerpc-serial.dpatch bugfix powerpc-pegasos-via82cxxx.dpatch bugfix powerpc-pegasos-2.dpatch feature powerpc-g4-l2-flush-errata.dpatch bugfix modular-vesafb.dpatch feature modular-vesafb-2.dpatch feature modular-ide.dpatchbugfix modular-ide-pnp.dpatchfeature modular-ide-2.dpatch feature marvell-pegasos.dpatchfeature ia64-irq-affinity-upfix.dpatchbuild ia64-generic-no-smp.dpatchbuild ia64-generic-no-smp-1-to-2.dpatch build ia64-bte_error-missing-include.dpatch build fs-asfs.dpatchfeature fix-mxser-compile.dpatch build drm-locking-fixes.dpatch crashfix drivers-scsi_changer.dpatch feature drivers-net-tg3-readd.dpatch license drivers-net-8139too-locking.dpatchcrashfix drivers-input-psaux-hacks.dpatch feature drivers-ide-dma-blacklist-toshiba.dpatch bugfix drivers-ide-__devinit.dpatch cleanup doc-post_halloween.dpatch documentation alsa-module-load-fix.dpatch crashfix 032-do_brk_security_fixes.dpatch security 031-sg_scsi_ioctl_int_overflows.dpatchsecurity 030-moxa_user_copy_checking.dpatchsecurity 029-random_poolsize_overflow.dpatch security 028-do_brk_security_fixes.dpatch security 027-track_dummy_capability-2.dpatch cleanup This actually fixes 025. It could be considered security, or cleanup, or patchfix. Kind of hard to classify it with one word. 026-nfs_o_direct_error.dpatch
