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.dpatch bugfix > modular-ide-pnp.dpatch feature > modular-ide-2.dpatch feature > 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.dpatch build > drm-locking-fixes.dpatch crashfix > drivers-scsi_changer.dpatch feature > drivers-net-tg3-readd.dpatch license > drivers-net-8139too-locking.dpatch crashfix > 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.dpatch security > 030-moxa_user_copy_checking.dpatch security > 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 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.dpatch bugfix > 016-cs461x_gameport.dpatch feature This isn't really a feature; it's a bugfix. Or build fix. > 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.dpatch bugfix > 011-parport_pc_module_parm_mixing.dpatch cleanup > 010-sparc64_macro_pmd_offset.dpatch cleanup > 009-ipt_ecn_corrupt_chksum.dpatch bugfix > 008-sock_without_ipv6.dpatch build > 007-pci_ide_no_reserve.dpatch bugfix > 006-zatm_cast_fix_fix.dpatch build > 005-sparc64_no_i_sock-2.dpatch patchfix > 004-sparc64_no_i_sock.dpatch build > 003-libata_alpha_build_fix.dpatch build > 002-pio_err_handling.dpatch bugfix > 001-acpi_ibm_exit.dpatch cleanup Not really a cleanup; bugfix, possibly an oopsable bugfix. > 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. > This doesn't scale for a large number of patches. > Additionally, maybe the bugfix category needs to be split into more > categories, we have too many patches in that category. > A bugfix is a bugfix. If you need to know more about it, you should read the description in the changelog, bug report, patch's description, bitkeeper, and finally google for it. Attempting to classify a bugfix with a single word is difficult. You've run into the main problem yourself, attempting to classifying the above; you have a whole bunch of bugfixes. That's what we'd end up calling everything. Assume everything is a bugfix. Currently, we have more than a few patches that aren't; those will go down w/ time. We need to either drop those, or get them applied upstream; forward porting from kernel to kernel is a huge pain. > The categorization may be wrong since I don't have too much clue with > kernel hacking and did this categorization mainly from the comments of > the patch. In my opinion, it would be desireable that a patch be > categorized by the kernel team on inclusion into Debian svn. > Debian kernel-source packages are intended to be used w/ all their patches together. The point of splitting them out into separate patches is so they can easily be unapplied, if you find a specific patch that's broken. It is *not* to allow users to pick specific patches and use them. Patches *will* depend on other patches, sometimes in non-obvious ways (for example; patch foo.dpatch may fix a bug in a function's return value; patch bar.dpatch is then necessary because something else was oopsing due to expecting the old, broken return value). If you grab foo.dpatch and not bar.dpatch, it will cause your kernel to oops. If you grab bar.dpatch (seeing as it fixes an oops) and not foo.dpatch, it won't really fix anything; it might even cause problems, as the bug in the original function is now not worked around. Combining the two patches, at least with our current kernel packaging, is not an option. Listing the patches as dependencies (patchfix or whatever) starts to become problematic when you have chains of patches; foo.dpatch fixes a bug, bar.dpatch fixes a bug in foo.dpatch, and baz.dpatch fixes a bug introduced by bar.dpatch.
