1. 11 Apr, 2018 1 commit
    • Miguel Ojeda's avatar
      clang-format: add configuration file · d4ef8d3f
      Miguel Ojeda authored
      clang-format is a tool to format C/C++/...  code according to a set of
      rules and heuristics.  Like most tools, it is not perfect nor covers
      every single case, but it is good enough to be helpful.
      In particular, it is useful for quickly re-formatting blocks of code
      automatically, for reviewing full files in order to spot coding style
      mistakes, typos and possible improvements.  It is also handy for sorting
      ``#includes``, for aligning variables and macros, for reflowing text and
      other similar tasks.  It also serves as a teaching tool/guide for
      The tool itself has been already included in the repositories of popular
      Linux distributions for a long time.  The rules in this file are
      intended for clang-format >= 4, which is easily available in most
      This commit adds the configuration file that contains the rules that the
      tool uses to know how to format the code according to the kernel coding
      style.  This gives us several advantages:
        * clang-format works out of the box with reasonable defaults;
          avoiding that everyone has to re-do the configuration.
        * Everyone agrees (eventually) on what is the most useful default
          configuration for most of the kernel.
        * If it becomes commonplace among kernel developers, clang-format
          may feel compelled to support us better. They already recognize
          the Linux kernel and its style in their documentation and in one
          of the style sub-options.
      Some of clang-format's features relevant for the kernel are:
        * Uses clang's tooling support behind the scenes to parse and rewrite
          the code. It is not based on ad-hoc regexps.
        * Supports reasonably well the Linux kernel coding style.
        * Fast enough to be used at the press of a key.
        * There are already integrations (either built-in or third-party)
          for many common editors used by kernel developers (e.g. vim,
          emacs, Sublime, Atom...) that allow you to format an entire file
          or, more usefully, just your selection.
        * Able to parse unified diffs -- you can, for instance, reformat
          only the lines changed by a git commit.
        * Able to reflow text comments as well.
        * Widely supported and used by hundreds of developers in highly
          complex projects and organizations (e.g. the LLVM project itself,
          Chromium, WebKit, Google, Mozilla...). Therefore, it will be
          supported for a long time.
      See more information about the tool at:
      Link: http://lkml.kernel.org/r/20180318171632.qfkemw3mwbcukth6@gmail.comSigned-off-by: default avatarMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 07 Apr, 2018 3 commits
  3. 25 Mar, 2018 1 commit
  4. 14 Feb, 2018 1 commit
  5. 12 Dec, 2017 1 commit
    • Paolo Pisati's avatar
      scripts/package: snap-pkg target · 5704d455
      Paolo Pisati authored
      Following in footsteps of other targets like 'deb-pkg, 'rpm-pkg' and 'tar-pkg',
      this patch adds a 'snap-pkg' target for the creation of a Linux kernel snap
      package using the kbuild infrastructure.
      A snap, in its general form, is a self contained, sandboxed, universal package
      and it is intended to work across multiple distributions and/or devices. A snap
      package is distributed as a single compressed squashfs filesystem.
      A kernel snap is a snap package carrying the Linux kernel, kernel modules,
      accessory files (DTBs, System.map, etc) and a manifesto file.  The purpose of a
      kernel snap is to carry the Linux kernel during the creation of a system image,
      eg. Ubuntu Core, and its subsequent upgrades.
      For more information on snap packages: https://snapcraft.io/docs/Signed-off-by: default avatarPaolo Pisati <paolo.pisati@canonical.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  6. 14 Nov, 2017 1 commit
  7. 08 Nov, 2017 2 commits
  8. 24 Apr, 2017 1 commit
  9. 22 Jul, 2016 1 commit
    • Luis R. Rodriguez's avatar
      scripts: add Linux .cocciconfig for coccinelle · dd951fc1
      Luis R. Rodriguez authored
      Coccinelle supports reading .cocciconfig, the order of precedence for
      variables for .cocciconfig is as follows:
       o Your current user's home directory is processed first
       o Your directory from which spatch is called is processed next
       o The directory provided with the --dir option is processed last, if used
      Since coccicheck runs through make, it naturally runs from the kernel
      proper dir, as such the second rule above would be implied for picking up a
      .cocciconfig when using 'make coccicheck'.
      'make coccicheck' also supports using M= targets.If you do not supply
      any M= target, it is assumed you want to target the entire kernel.
      The kernel coccicheck script has:
          if [ "$KBUILD_EXTMOD" = "" ] ; then
              OPTIONS="--dir $srctree $COCCIINCLUDE"
      KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
      the spatch --dir argument is used, as such third rule applies when
      whether M= is used or not, and when M= is used the target directory can
      have its own .cocciconfig file. When M= is not passed as an argument to
      coccicheck the target directory is the same as the directory from where
      spatch was called.
      If not using the kernel's coccicheck target, keep the above precedence order
      logic of .cocciconfig reading. If using the kernel's coccicheck target,
      override any of the kernel's .coccicheck's settings using SPFLAGS.
      We help Coccinelle when used against Linux with a set of sensible defaults
      options for Linux with our own Linux .cocciconfig. This hints to coccinelle
      git can be used for 'git grep' queries over coccigrep. A timeout of 200
      seconds should suffice for now.
      The options picked up by coccinelle when reading a .cocciconfig do not appear
      as arguments to spatch processes running on your system, to confirm what
      options will be used by Coccinelle run:
        spatch --print-options-only
      You can override with your own preferred index option by using SPFLAGS.
      Coccinelle supports both glimpse and idutils. Glimpse had historically
      provided the best performance, however recent benchmarks reveal idutils
      is performing just as well. Due to some recent fixes however you however
      will need at least coccinelle >= 1.0.6 if using idutils.
      Coccinelle carries a script scripts/idutils_index.sh which creates the
      idutils database with as follows:
          mkid -i C --output .id-utils.index
      If using just "--use-idutils" coccinelle expects your idutils database to be
      on the top level of the kernel as a file named ".id-utils.index". If you do
      not use this you can symlink your database file to it, or you can specify the
      database file following the "--use-idutils" argument. Examples:
          make SPFLAGS=--use-idutils coccicheck
      This assumes you have $srctree/.id-utils.index, where $srctree is
      the top level of the kernel.
          make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
      Here you specify the full path of the idutils ID database. Using
      .cocciconfig is possible, however given the order of precedence followed
      by Coccinelle, and since the kernel now carries its own .cocciconfig,
      you will need to use SPFLAGS to use idutils if desired.
      o Recommend upgrade for using idutils with coccinelle due to some
        recent fixes.
      o Refer to using --print-options-only for testing what options are
        picked up by .cocciconfig reading.
      o Expand commit log considerably explaining *why* .cocconfig from
        two precedence rules are used when using coccicheck, and how to
        properly override these if needed.
      o Expand Documentation/coccinelle.txt
      v3: Expand commit log a bit more
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Acked-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  10. 07 Jun, 2016 1 commit
    • Emese Revfy's avatar
      GCC plugin infrastructure · 6b90bd4b
      Emese Revfy authored
      This patch allows to build the whole kernel with GCC plugins. It was ported from
      grsecurity/PaX. The infrastructure supports building out-of-tree modules and
      building in a separate directory. Cross-compilation is supported too.
      Currently the x86, arm, arm64 and uml architectures enable plugins.
      The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory
      there. The plugins compile with these options:
       * -fno-rtti: gcc is compiled with this option so the plugins must use it too
       * -fno-exceptions: this is inherited from gcc too
       * -fasynchronous-unwind-tables: this is inherited from gcc too
       * -ggdb: it is useful for debugging a plugin (better backtrace on internal
       * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
       * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
          variable, plugin-version.h)
      The infrastructure introduces a new Makefile target called gcc-plugins. It
      supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
      chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
      This script also checks the availability of the included headers in
      The gcc-common.h header contains frequently included headers for GCC plugins
      and it has a compatibility layer for the supported gcc versions.
      The gcc-generate-*-pass.h headers automatically generate the registration
      structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.
      Note that 'make clean' keeps the *.so files (only the distclean or mrproper
      targets clean all) because they are needed for out-of-tree modules.
      Based on work created by the PaX Team.
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  11. 28 Apr, 2016 1 commit
  12. 28 Aug, 2015 1 commit
  13. 07 Aug, 2015 1 commit
    • David Woodhouse's avatar
      modsign: Use single PEM file for autogenerated key · fb117949
      David Woodhouse authored
      The current rule for generating signing_key.priv and signing_key.x509 is
      a classic example of a bad rule which has a tendency to break parallel
      make. When invoked to create *either* target, it generates the other
      target as a side-effect that make didn't predict.
      So let's switch to using a single file signing_key.pem which contains
      both key and certificate. That matches what we do in the case of an
      external key specified by CONFIG_MODULE_SIG_KEY anyway, so it's also
      slightly cleaner.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  14. 15 Jun, 2015 2 commits
  15. 17 Apr, 2015 1 commit
  16. 17 Feb, 2015 1 commit
  17. 13 Feb, 2015 1 commit
  18. 27 Nov, 2014 1 commit
  19. 25 Nov, 2014 1 commit
  20. 27 Oct, 2014 1 commit
  21. 30 Jul, 2014 1 commit
    • Andi Kleen's avatar
      kbuild: Support split debug info v4 · 866ced95
      Andi Kleen authored
      This is an alternative approach to lower the overhead of debug info
      (as we discussed a few days ago)
      gcc 4.7+ and newer binutils have a new "split debug info" debug info
      model where the debug info is only written once into central ".dwo" files.
      This avoids having to copy it around multiple times, from the object
      files to the final executable. It lowers the disk space
      requirements. In addition it defaults to compressed debug data.
      More details here: http://gcc.gnu.org/wiki/DebugFission
      This patch adds a new option to enable it. It has to be an option,
      because it'll undoubtedly break everyone's debuginfo packaging scheme.
      gdb/objdump/etc. all still work, if you have new enough versions.
      I don't see big compile wins (maybe a second or two faster or so), but the
      object dirs with debuginfo get significantly smaller. My standard kernel
      config (slightly bigger than defconfig) shrinks from 2.9G disk space
      to 1.1G objdir (with non reduced debuginfo). I presume if you are IO limited
      the compile time difference will be larger.
      Only problem I've seen so far is that it doesn't play well with older
      versions of ccache (apparently fixed, see
      v2: various fixes from Dirk Gouders. Improve commit message slightly.
      v3: Fix clean rules and improve Kconfig slightly
      v4: Fix merge error in last version (Sam Ravnborg)
          Clarify description that it mainly helps disk size.
      Cc: Dirk Gouders <dirk@gouders.net>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  22. 16 Apr, 2014 1 commit
  23. 11 Feb, 2014 1 commit
  24. 31 Jul, 2013 1 commit
  25. 18 Dec, 2012 1 commit
  26. 19 Oct, 2012 1 commit
  27. 10 Oct, 2012 1 commit
  28. 01 Jul, 2011 1 commit
  29. 28 Apr, 2011 1 commit
    • Sam Ravnborg's avatar
      kbuild: asm-generic support · d8ecc5cd
      Sam Ravnborg authored
      There is an increasing amount of header files
      shared between individual architectures in asm-generic.
      To avoid a lot of dummy wrapper files that just
      include the corresponding file in asm-generic provide
      some basic support in kbuild for this.
      With the following patch an architecture can maintain
      a list of files in the file arch/$(ARCH)/include/asm/Kbuild
      To use a generic file just add:
              generic-y += <name-of-header-file.h>
      For each file listed kbuild will generate the necessary
      wrapper in arch/$(ARCH)/include/generated/asm.
      When installing userspace headers a wrapper is likewise created.
      The original inspiration for this came from the unicore32
      patchset - although a different method is used.
      The patch includes several improvements from Arnd Bergmann.
      Michael Marek contributed Makefile.asm-generic.
      Remis Baima did an intial implementation along to achive
      the same - see https://patchwork.kernel.org/patch/13352/Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Acked-by: default avatarGuan Xuetao <guanxuetao@mprc.pku.edu.cn>
      Tested-by: default avatarGuan Xuetao <guanxuetao@mprc.pku.edu.cn>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Remis Lima Baima <remis.developer@googlemail.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  30. 22 Feb, 2011 1 commit
  31. 23 Mar, 2010 1 commit
  32. 13 Mar, 2010 1 commit
  33. 06 Mar, 2010 1 commit
  34. 11 Jan, 2010 1 commit
  35. 12 Dec, 2009 2 commits