compat: backport PCI: Add accessors for PCI Express Capability

This backports this patch:

commit 8c0d3a02c1309eb6112d2e7c8172e8ceb26ecfca
Author: Jiang Liu <jiang.liu@huawei.com>
Date:   Tue Jul 24 17:20:05 2012 +0800

    PCI: Add accessors for PCI Express Capability

    The PCI Express Capability (PCIe spec r3.0, sec 7.8) comes in two
    versions, v1 and v2.  In v1 Capability structures (PCIe spec r1.0 and
    r1.1), some fields are optional, so the structure size depends on the
    device type.

    This patch adds functions to access this capability so drivers don't
    have to be aware of the differences between v1 and v2.  Note that these
    new functions apply only to the "PCI Express Capability," not to any of
    the other "PCI Express Extended Capabilities" (AER, VC, ACS, MFVC, etc.)

    Function pcie_capability_read_word/dword() reads the PCIe Capabilities
    register and returns the value in the reference parameter "val".  If
    the PCIe Capabilities register is not implemented on the PCIe device,
    "val" is set to 0.

    Function pcie_capability_write_word/dword() writes the value to the
    specified PCIe Capability register.

    Function pcie_capability_clear_and_set_word/dword() sets and/or clears bits
    of a PCIe Capability register.

    [bhelgaas: changelog, drop "pci_" prefixes, don't export
    pcie_capability_reg_implemented()]
    Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
    Signed-off-by: Yijing Wang <wangyijing@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

This is not yet upstream into a public release but based on
star alignments I can confidently say this will be part
of the v3.7-rc1 release unless Linus throws a shit fit over
it.

Worth mentioning is that the pci_dev->pcie_flags_reg
is not available on older kernels so we had to write
a pcie_flags_reg() helper. Additionally a lot of pci_reg.h
updates were made into the respective header file as they
were introduced.

mcgrof@garbanzo ~/compat (git::master)$ time ckmake
Trying kernel 3.5.0-030500-generic [OK]
Trying kernel 3.4.4-030404-generic [OK]
Trying kernel 3.3.7-030307-generic [OK]
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]

real    0m59.966s
user    3m12.628s
sys     0m29.542s

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: fix ARM architecture support for atomic_t and atomic64_t changes

This ammends the patch below to extend support for ARM.

commit e079e9b66ea06373a3be82f9bed1702082a69310
Author: Luis R. Rodriguez <mcgrof@frijolero.org>
Date:   Tue Feb 7 19:22:02 2012 -0800

    compat: backport making atomic_t and atomic64_t universal

    mcgrof@tux ~/linux-next (git::master)$ \
        git describe --contains ea435467500612636f8f4fb639ff6e76b2496e4b
    v2.6.29-rc1~390

    This commit moved atomic_t and atomic64_t to a generic
    place, but some archs already had it defined. Just include
    that header for the archs that had it.

    Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org>

ARM also had atomic.h before that commit upstream.

Signed-off-by: Mridula Prakash <Mridula.Prakash@lnties.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: fix typo on previous atomic changes

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: drop const to fix compiler warnings

When calling pci_find_capability and pci_read_config_word, struct pci_dev
needs to be passed without const.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport netlink pid to portid rename

The patch:

commit 15e473046cb6e5d18a4d0057e61d76315230382b
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Sep 7 20:12:54 2012 +0000

    netlink: Rename pid to portid to avoid confusion

    It is a frequent mistake to confuse the netlink port identifier with a
    process identifier.  Try to reduce this confusion by renaming fields
    that hold port identifiers portid instead of pid.

    I have carefully avoided changing the structures exported to
    userspace to avoid changing the userspace API.

    I have successfully built an allyesconfig kernel with this change.

    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Acked-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Changed the struct members:

struct netlink_notify->pid    to
struct netlink_notify->portid

struct genl_info->snd_pid     to
struct genl_info->snd_portid

This adds helpers to help reduce the overhead cost to backport
this collateral evolution.

mcgrof@garbanzo ~/compat (git::master)$ time ckmake
Trying kernel 3.5.0-030500-generic [OK]
Trying kernel 3.4.4-030404-generic [OK]
Trying kernel 3.3.7-030307-generic [OK]
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]

real    1m0.017s
user    3m12.748s
sys     0m30.274s

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport uidgid.h kuid_t and kgid_t addition

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \
	7a4e7408c5cadb240e068a662251754a562355e3
v3.5-rc1~107^2~33

This backports:

commit 7a4e7408c5cadb240e068a662251754a562355e3
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Nov 14 14:29:51 2011 -0800

    userns: Add kuid_t and kgid_t and associated infrastructure in uidgid.h

    Start distinguishing between internal kernel uids and gids and
    values that userspace can use.  This is done by introducing two
    new types: kuid_t and kgid_t.  These types and their associated
    functions are infrastructure are declared in the new header
    uidgid.h.

    Ultimately there will be a different implementation of the mapping
    functions for use with user namespaces.  But to keep it simple
    we introduce the mapping functions first to separate the meat
    from the mechanical code conversions.

    Export overflowuid and overflowgid so we can use from_kuid_munged
    and from_kgid_munged in modular code.

    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

The uidgid.h header file is provided for older kernels and for
newer kernels we use include_next trick. The only difference
here is that compat-3.5.c now exports overflowuid and
overflowgid in the case that CONFIG_UID16 was not defined
given that on older kernels these were not exported although
linux/highuid.h always has historically provided the extern
declaration for them.

Apart from all this we also force inclusion of uidgid.h
within the compat framework now given that in newer
kernels its expected to be included by many header files
and modules without them having included it in upstream
code already.

mcgrof@garbanzo ~/compat (git::master)$ time ckmake
Trying kernel 3.5.0-030500-generic [OK]
Trying kernel 3.4.4-030404-generic [OK]
Trying kernel 3.3.7-030307-generic [OK]
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]

real	1m0.411s
user	3m18.060s
sys	0m30.686s

Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport definition of VM_NODUMP and VM_DONTDUMP

Commit accb61fe defined and added VM_NODUMP so we backport that
but later VM_NODUMP was renamed to VM_DONTDUMP via commit cdaaa7003.
We backport that definition declaration as well. Note though that
commit 909af768e removed the usage of the same bit field and it
was used previously for VM_ALWAYSDUMP... given that we want to
backport support for it but we can't we make this flag now a no-op
for older kernels.

Usage of VM_NODUMP or VM_DONTDUMP on older kernels will simply yield
in a no-op for memory regions.

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains \
	909af768e88867016f427264ae39d27a57b6a8ed
v3.4-rc1~109^2~7

commit 909af768e88867016f427264ae39d27a57b6a8ed
Author: Jason Baron <jbaron@redhat.com>
Date:   Fri Mar 23 15:02:51 2012 -0700

    coredump: remove VM_ALWAYSDUMP flag

    The motivation for this patchset was that I was looking at a way for a
    qemu-kvm process, to exclude the guest memory from its core dump, which
    can be quite large.  There are already a number of filter flags in
    /proc/<pid>/coredump_filter, however, these allow one to specify 'types'
    of kernel memory, not specific address ranges (which is needed in this
    case).

    Since there are no more vma flags available, the first patch eliminates
    the need for the 'VM_ALWAYSDUMP' flag.  The flag is used internally by
    the kernel to mark vdso and vsyscall pages.  However, it is simple
    enough to check if a vma covers a vdso or vsyscall page without the need
    for this flag.

    The second patch then replaces the 'VM_ALWAYSDUMP' flag with a new
    'VM_NODUMP' flag, which can be set by userspace using new madvise flags:
    'MADV_DONTDUMP', and unset via 'MADV_DODUMP'.  The core dump filters
    continue to work the same as before unless 'MADV_DONTDUMP' is set on the
    region.

    The qemu code which implements this features is at:

      http://people.redhat.com/~jbaron/qemu-dump/qemu-dump.patch

    In my testing the qemu core dump shrunk from 383MB -> 13MB with this
    patch.

    I also believe that the 'MADV_DONTDUMP' flag might be useful for
    security sensitive apps, which might want to select which areas are
    dumped.

    This patch:

    The VM_ALWAYSDUMP flag is currently used by the coredump code to
    indicate that a vma is part of a vsyscall or vdso section.  However, we
    can determine if a vma is in one these sections by checking it against
    the gate_vma and checking for a non-NULL return value from
    arch_vma_name().  Thus, freeing a valuable vma bit.

    Signed-off-by: Jason Baron <jbaron@redhat.com>
    Acked-by: Roland McGrath <roland@hack.frob.com>
    Cc: Chris Metcalf <cmetcalf@tilera.com>
    Cc: Avi Kivity <avi@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mcgrof@frijol ~/linux-next (git::master)$ git describe --contains accb61fe
v3.4-rc1~109^2~6

commit accb61fe7bb0f5c2a4102239e4981650f9048519
Author: Jason Baron <jbaron@redhat.com>
Date:   Fri Mar 23 15:02:51 2012 -0700

    coredump: add VM_NODUMP, MADV_NODUMP, MADV_CLEAR_NODUMP

    Since we no longer need the VM_ALWAYSDUMP flag, let's use the freed bit
    for 'VM_NODUMP' flag.  The idea is is to add a new madvise() flag:
    MADV_DONTDUMP, which can be set by applications to specifically request
    memory regions which should not dump core.

    The specific application I have in mind is qemu: we can add a flag there
    that wouldn't dump all of guest memory when qemu dumps core.  This flag
    might also be useful for security sensitive apps that want to absolutely
    make sure that parts of memory are not dumped.  To clear the flag use:
    MADV_DODUMP.

    [akpm@linux-foundation.org: s/MADV_NODUMP/MADV_DONTDUMP/, s/MADV_CLEAR_NODUMP/MADV_DODUMP/, per Roland]
    [akpm@linux-foundation.org: fix up the architectures which broke]
    Signed-off-by: Jason Baron <jbaron@redhat.com>
    Acked-by: Roland McGrath <roland@hack.frob.com>
    Cc: Chris Metcalf <cmetcalf@tilera.com>
    Cc: Avi Kivity <avi@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Richard Henderson <rth@twiddle.net>
    Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
    Cc: Matt Turner <mattst88@gmail.com>
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

VM_NODUMP was renamed to VM_DONTDUMP so for older kernels
just use the old declaration. This commit is not yet on
Linus' tree so in linux-next we trust it will be on v3.7-rc1.

commit cdaaa7003e855fb50be3a566ac8ef96c6ff138cd
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Wed Sep 26 11:33:12 2012 +1000

    mm: prepare VM_DONTDUMP for using in drivers

    Rename VM_NODUMP into VM_DONTDUMP: this name matches other negative flags:
    VM_DONTEXPAND, VM_DONTCOPY.  Currently this flag used only for
    sys_madvise.  The next patch will use it for replacing the outdated flag
    VM_RESERVED.

    Also forbid madvise(MADV_DODUMP) for special kernel mappings VM_SPECIAL
    (VM_IO | VM_DONTEXPAND | VM_RESERVED | VM_PFNMAP)

    Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Carsten Otte <cotte@de.ibm.com>
    Cc: Chris Metcalf <cmetcalf@tilera.com>
    Cc: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: Eric Paris <eparis@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Cc: Jason Baron <jbaron@redhat.com>
    Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
    Cc: Matt Helsley <matthltc@us.ibm.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Robert Richter <robert.richter@amd.com>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Venkatesh Pallipadi <venki@google.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Cc: Jason Baron <jbaron@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport seq_file's user namespace addition

Commit adb37c4, which as per linux-next may get to
v3.7-rc1, introduced adding a user namespace to a
struct seq_file. For older kernels with CONFIG_USER_NS
support just access the user_name space via the struct
file. For kernels without CONFIG_USER_NS pass the
init_user_ns. There is a special case to handle for
kernels with CONFIG_USER_NS prior to v2.6.38 --
see commit 47a150ed which added a struct user_namespace
to struct cred.

This backports:

commit adb37c4c67f807f16beb222028fb3ce9a354dc2b
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Wed May 23 18:01:20 2012 -0600

    userns: Make seq_file's user namespace accessible

    struct file already has a user namespace associated with it
    in file->f_cred->user_ns, unfortunately because struct
    seq_file has no struct file backpointer associated with
    it, it is difficult to get at the user namespace in seq_file
    context.  Therefore add a helper function seq_user_ns to return
    the associated user namespace and a user_ns field to struct
    seq_file to be used in implementing seq_user_ns.

    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

And for kernels older than v2.6.38 this is relevant to
review:

commit 47a150edc2ae734c0f4bf50aa19499e23b9a46f8
Author: Serge E. Hallyn <serge.hallyn@canonical.com>
Date:   Fri May 13 04:27:54 2011 +0100

    Cache user_ns in struct cred

    If !CONFIG_USERNS, have current_user_ns() defined to (&init_user_ns).

    Get rid of _current_user_ns.  This requires nsown_capable() to be
    defined in capability.c rather than as static inline in capability.h,
    so do that.

    Request_key needs init_user_ns defined at current_user_ns if
    !CONFIG_USERNS, so forward-declare that in cred.h if !CONFIG_USERNS
    at current_user_ns() define.

    Compile-tested with and without CONFIG_USERNS.

    Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
    [ This makes a huge performance difference for acl_permission_check(),
      up to 30%.  And that is one of the hottest kernel functions for loads
      that are pathname-lookup heavy.  ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mcgrof@garbanzo ~/compat (git::master)$ time ckmake
Trying kernel 3.5.0-030500-generic [OK]
Trying kernel 3.4.4-030404-generic [OK]
Trying kernel 3.3.7-030307-generic [OK]
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]

real	1m1.219s
user	3m19.912s
sys	0m31.102s

Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: backport usb_autopm_[get|put]_interface_no_[resume|suspend]()

This backports these two routines:

  * usb_autopm_get_interface_no_resume()
  * usb_autopm_put_interface_no_suspend()

These routines simply increment or decrement the USB
pm usage counter without trying to either suspend or
resume.

mcgrof@garbanzo ~/compat (git::master)$ time ckmake
Trying kernel 3.5.0-030500-generic [OK]
Trying kernel 3.4.4-030404-generic [OK]
Trying kernel 3.3.7-030307-generic [OK]
Trying kernel 3.2.2-030202-generic [OK]
Trying kernel 3.1.10-030110-generic [OK]
Trying kernel 3.0.18-030018-generic [OK]
Trying kernel 2.6.39-02063904-generic [OK]
Trying kernel 2.6.38-02063808-generic [OK]
Trying kernel 2.6.37-02063706-generic [OK]
Trying kernel 2.6.36-02063604-generic [OK]
Trying kernel 2.6.35-02063512-generic [OK]
Trying kernel 2.6.34-02063410-generic [OK]
Trying kernel 2.6.33-02063305-generic [OK]
Trying kernel 2.6.32-02063255-generic [OK]
Trying kernel 2.6.31-02063113-generic [OK]
Trying kernel 2.6.30-02063010-generic [OK]
Trying kernel 2.6.29-02062906-generic [OK]
Trying kernel 2.6.28-02062810-generic [OK]
Trying kernel 2.6.27-020627-generic [OK]
Trying kernel 2.6.26-020626-generic [OK]
Trying kernel 2.6.25-020625-generic [OK]
Trying kernel 2.6.24-020624-generic [OK]

real    1m2.113s
user    3m30.573s
sys     0m31.922s

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: fix first ckmake make clean assumption

Any directory should be used to make the first
'make clean' but we should get that from the KLIBS
variable. Use the first kernel found that we can
use. This fixes a complaint when your current kernel
has no kernel headers installed but you do have some
present on the compat-ksrc dir.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: add v3.6.2 vanilla kernels to bin/get-compat-kernels

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: encourage non-root use of bin/get-compat-kernels

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
compat: update list of kernel headers

With this patch get-compat-kernels fetches the most recent minor
versions of the kernel headers from the Ubuntu mainline repository.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>