1. 25 Mar, 2018 1 commit
    • Nicholas Piggin's avatar
      kbuild: rename built-in.o to built-in.a · f49821ee
      Nicholas Piggin authored
      Incremental linking is gone, so rename built-in.o to built-in.a, which
      is the usual extension for archive files.
      
      This patch does two things, first is a simple search/replace:
      
      git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g'
      
      The second is to invert nesting of nested text manipulations to avoid
      filtering built-in.a out from libs-y2:
      
      -libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y)))
      +libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f49821ee
  2. 16 Dec, 2017 1 commit
    • Masahiro Yamada's avatar
      kbuild: prepare to remove C files pre-generated by flex and bison · 033dba2e
      Masahiro Yamada authored
      In Linux build system convention, pre-generated files are version-
      controlled with a "_shipped" suffix.  During the kernel building,
      they are simply shipped (copied) removing the suffix.
      
      This approach can reduce external tool dependency for the kernel build,
      but it is tedious to manually regenerate such artifacts from developers'
      point of view.  (We need to do "make REGENERATE_PARSERS=1" every time
      we touch real source files such as *.l, *.y)
      
      Some months ago, I sent out RFC patches to run flex, bison, and gperf
      during the build.
      
      In the review and test, Linus noticed gperf-3.1 had changed the lookup
      function prototype.  Then, the use of gperf in kernel was entirely
      removed by commit bb3290d9 ("Remove gperf usage from toolchain").
      
      This time, I tested several versions of flex and bison, and I was not
      hit by any compatibility issue except a flaw in flex-2.6.3; if you
      generate lexer for dtc and genksyms with flex-2.6.3, you will see
      "yywrap redefined" warning.  This was not intentional, but a bug,
      fixed by flex-2.6.4.  Otherwise, both flex and bison look fairly
      stable for a long time.
      
      This commit prepares some build rules to remove the _shipped files.
      Also, document minimal requirement for flex and bison.
      
      Rationale for the minimal version:
      The -Wmissing-prototypes option of GCC warns "no previous prototype"
      for lexers generated by flex-2.5.34 or older, so I chose 2.5.35 as the
      required version for flex.  Flex-2.5.35 was released in 2008.  Bison
      looks more stable.  I did not see any problem with bison-2.0, released
      in 2004.  I did not test bison-1.x, but bison-2.0 should be old enough.
      
      Tested flex versions:
        2.5.35
        2.5.36
        2.5.37
        2.5.39
        2.6.0
        2.6.1
        2.6.2
        2.6.3   (*)
        2.6.4
      
       (*) flex-2.6.3 causes "yywrap redefined" warning
      
      Tested bison versions:
        2.0
        2.1
        2.2
        2.3
        2.4
        2.4.1
        2.5.1
        2.6
        2.6.1
        2.6.2
        2.6.3
        2.6.4
        2.6.5
        2.7
        2.7.1
        3.0
        3.0.1
        3.0.2
        3.0.3
        3.0.4
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      033dba2e
  3. 17 Jul, 2017 2 commits
  4. 30 Jun, 2017 1 commit
  5. 16 May, 2017 1 commit
  6. 07 May, 2017 1 commit
  7. 06 May, 2017 1 commit
    • Masahiro Yamada's avatar
      docs: bump minimal GNU Make version to 3.81 · 37d69ee3
      Masahiro Yamada authored
      Since 2014, you can't successfully build kernels with GNU Make version
      3.80. Example errors:
      
        $ git describe
        v4.11
        $ make --version | head -1
        GNU Make 3.80
        $ make defconfig
          HOSTCC  scripts/basic/fixdep
        scripts/Makefile.host:135: *** missing separator.  Stop.
        make: *** [defconfig] Error 2
        $ make ARCH=arm64 help
        arch/arm64/Makefile:43: *** unterminated call to function `warning': missing `)'.  Stop.
        $ make help >/dev/null
        ./Documentation/Makefile.sphinx:25: Extraneous text after `else' directive
        ./Documentation/Makefile.sphinx:31: *** only one `else' per conditional.  Stop.
        make: *** [help] Error 2
      
      The first breakage was introduced by commit c8589d1e ("kbuild:
      handle multi-objs dependency appropriately").  Since then (i.e. v3.18),
      GNU Make 3.80 has not been able to compile the kernel, but nobody has
      ever complained aboutt (or noticed) it.
      
      Even GNU Make 3.81 is more than 10 years old.  It would not hurt to
      match the documentation with reality instead of fixing makefiles.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      37d69ee3
  8. 29 Mar, 2017 1 commit
  9. 09 Mar, 2017 1 commit
    • Markus Heiser's avatar
      docs-rst: automatically convert Graphviz and SVG images · db6ccf23
      Markus Heiser authored
      This patch brings scalable figure, image handling and a concept to
      embed *render* markups:
      
      * DOT (http://www.graphviz.org)
      * SVG
      
      For image handling use the 'image' replacement::
      
          .. kernel-image::  svg_image.svg
             :alt:    simple SVG image
      
      For figure handling use the 'figure' replacement::
      
          .. kernel-figure::  svg_image.svg
             :alt:    simple SVG image
      
             SVG image example
      
      Embed *render* markups (or languages) like Graphviz's **DOT** is
      provided by the *render* directive.::
      
        .. kernel-render:: DOT
           :alt: foobar digraph
           :caption: Embedded **DOT** (Graphviz) code.
      
           digraph foo {
            "bar" -> "baz";
           }
      
      The *render* directive is a concept to integrate *render* markups and
      languages, yet supported markups:
      
      * DOT: render embedded Graphviz's **DOT**
      * SVG: render embedded Scalable Vector Graphics (**SVG**)
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Tested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v2 - v5)
      Signed-off-by: Markus Heiser <markus.heiser@darmarit.de> (v1, v6)
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      db6ccf23
  10. 27 Oct, 2016 1 commit
  11. 24 Oct, 2016 1 commit
  12. 21 Sep, 2016 4 commits
  13. 11 Oct, 2015 1 commit
  14. 25 Sep, 2015 1 commit
    • David Howells's avatar
      MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too old · 283e8ba2
      David Howells authored
      The sign-file.c program actually uses CMS rather than PKCS#7 to sign a file
      since that allows the target X.509 certificate to be specified by
      subjectKeyId rather than by issuer + serialNumber.
      
      However, older versions of the OpenSSL crypto library (such as may be found
      in CentOS 5.11) don't support CMS.  Assume everything prior to
      OpenSSL-1.0.0 doesn't support CMS and switch to using PKCS#7 in that case.
      
      Further, the pre-1.0.0 OpenSSL only supports PKCS#7 signing with SHA1, so
      give an error from the sign-file script if the caller requests anything
      other than SHA1.
      
      The compiler gives the following error with an OpenSSL crypto library
      that's too old:
      
        HOSTCC  scripts/sign-file
      scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory
       #include <openssl/cms.h>
      Reported-by: default avatarVinson Lee <vlee@twopensource.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      283e8ba2
  15. 27 Aug, 2015 1 commit
  16. 29 Dec, 2014 1 commit
  17. 09 Dec, 2014 1 commit
  18. 09 Sep, 2014 2 commits
  19. 12 Jul, 2014 1 commit
  20. 19 May, 2014 1 commit
  21. 28 Nov, 2013 1 commit
  22. 11 Jul, 2011 1 commit
  23. 23 Mar, 2011 1 commit
  24. 11 Jul, 2010 1 commit
  25. 25 Mar, 2010 1 commit
  26. 14 Dec, 2009 1 commit
  27. 18 Jun, 2009 1 commit
  28. 14 Jun, 2009 1 commit
  29. 28 May, 2009 1 commit
  30. 30 Jan, 2009 1 commit
  31. 02 Aug, 2007 1 commit
  32. 30 Nov, 2006 1 commit
  33. 25 Sep, 2006 1 commit
  34. 26 Jun, 2006 1 commit
  35. 20 Mar, 2006 1 commit