lkml.org 
[lkml]   [2009]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [git-pull -tip] x86: include inverse Xmas tree patches
    From
    Date
    On Sat, 2009-03-28 at 18:58 +0300, Alexey Dobriyan wrote:
    > On Sat, Mar 28, 2009 at 03:55:49PM +0000, Alan Cox wrote:
    > > > kenel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-Xmas.git x86/core
    > > > >
    > > > > Jaswinder Singh Rajput (49):
    > > > > x86: process_32.c include inverse Xmas tree effect
    > > >
    > > > What the heck is this?
    > >
    > > Does inverse christmas tree effect not translate well. It could perhaps
    > > have been more clearly explained.
    > >
    > > Getting the includes under control is a good thing and saves everyone
    > > time.
    >
    > Moving #includes up and down is not getting them under control.

    Here is Ingo's response about this effect:

    On Sun, 2009-03-15 at 05:54 +0100, Ingo Molnar wrote:
    > * Li Zefan <lizf@cn.fujitsu.com> wrote:
    >
    > > > #include <linux/debugfs.h>
    > > > #include <linux/uaccess.h>
    > > > -#include <linux/stat.h>
    > > > +#include <linux/module.h>
    > > > #include <linux/init.h>
    > > > +#include <linux/stat.h>
    > > > #include <linux/io.h>
    > > > #include <linux/mm.h>
    > > > -#include <linux/module.h>
    > > >
    > >
    > > Just curious about the rule to sort those includes, and why they need
    > > to be rearranged.
    >
    > Such includes (the 'reverse christmas tree'):
    >
    > #include <linux/interrupt.h>
    > #include <linux/mmiotrace.h>
    > #include <linux/bootmem.h>
    > #include <linux/compiler.h>
    > #include <linux/highmem.h>
    > #include <linux/kprobes.h>
    > #include <linux/uaccess.h>
    > #include <linux/vmalloc.h>
    > #include <linux/vt_kern.h>
    > #include <linux/signal.h>
    > #include <linux/kernel.h>
    > #include <linux/ptrace.h>
    > #include <linux/string.h>
    > #include <linux/module.h>
    > #include <linux/kdebug.h>
    > #include <linux/errno.h>
    > #include <linux/magic.h>
    > #include <linux/sched.h>
    > #include <linux/types.h>
    > #include <linux/init.h>
    > #include <linux/mman.h>
    > #include <linux/tty.h>
    > #include <linux/smp.h>
    > #include <linux/mm.h>
    >
    > #include <asm/kmemcheck.h>
    > #include <asm/tlbflush.h>
    > #include <asm/pgalloc.h>
    > #include <asm/segment.h>
    > #include <asm/system.h>
    > #include <asm/proto.h>
    > #include <asm/traps.h>
    > #include <asm/desc.h>
    >
    > are used by x86 architecture code (and some other subsystems) to
    > reduce the likelyhood of patch conflicts in commonly modified
    > kernel files.
    >
    > Without such ordering developers typically append to the
    > existing list of include files when introducing a new header -
    > creating an almost certain patch conflict. Via the above
    > ordering, new headers get distributed roughly evenly amongst the
    > full range - and thus the chance of patch conflicts is much
    > smaller.
    >
    > This way it also looks a bit more structured and bit less messy.
    > It looks unprofessional and sloppy if a .c file starts with a
    > big block of thrown-together include files.
    >
    > Ingo




    \
     
     \ /
      Last update: 2009-03-28 17:15    [W:0.028 / U:59.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site