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.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.
Reply to: