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.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
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
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
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 many patches in that category.
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.
I would like to solicit your comments about this concept.
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
Reply to: