1. 29 11月, 2016 1 次提交
  2. 04 4月, 2014 1 次提交
    • J
      genksyms: fix typeof() handling · dc533240
      Jan Beulich 提交于
      Recent increased use of typeof() throughout the tree resulted in a
      number of symbols (25 in a typical distro config of ours) not getting a
      proper CRC calculated for them anymore, due to the parser in genksyms
      not coping with several of these uses (interestingly in the majority of
      [if not all] cases the problem is due to the use of typeof() in code
      preceding a certain export, not in the declaration/definition of the
      exported function/object itself; I wasn't able to find a way to address
      this more general parser shortcoming).
      
      The use of parameter_declaration is a little more relaxed than would be
      ideal (permitting not just a bare type specification, but also one with
      identifier), but since the same code is being passed through an actual
      compiler, there's no apparent risk of allowing through any broken code.
      
      Otoh using parameter_declaration instead of the ad hoc
      "decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to
      be handled rather than just plain ones and pointers to plain ones.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc533240
  3. 10 6月, 2011 1 次提交
  4. 12 12月, 2009 1 次提交
  5. 16 11月, 2009 1 次提交
    • J
      genksyms: Mark is_reserved_word static · ed9df091
      Josh Triplett 提交于
      The genksyms keyword gperf hash provides a function is_reserved_word.
      genksyms #includes the resulting generated file keywords.c, so the
      function gets used only in the same source file that defines it.  Mark
      is_reserved_word static, and regenerate the corresponding generated
      file.
      Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
      ed9df091
  6. 15 1月, 2009 1 次提交
  7. 20 12月, 2008 1 次提交
    • J
      allow stripping of generated symbols under CONFIG_KALLSYMS_ALL · 9bb48247
      Jan Beulich 提交于
      Building upon parts of the module stripping patch, this patch
      introduces similar stripping for vmlinux when CONFIG_KALLSYMS_ALL=y.
      Using CONFIG_KALLSYMS_STRIP_GENERATED reduces the overhead of
      CONFIG_KALLSYMS_ALL from 245k/310k to 65k/80k for the (i386/x86-64)
      kernels I tested with.
      
      The patch also does away with the need to special case the kallsyms-
      internal symbols by making them available even in the first linking
      stage.
      
      While it is a generated file, the patch includes the changes to
      scripts/genksyms/keywords.c_shipped, as I'm unsure what the procedure
      here is.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      9bb48247
  8. 13 10月, 2007 1 次提交
    • S
      kbuild: __extension__ support in genksyms (fix unknown CRC warning) · 3550a516
      Sam Ravnborg 提交于
      Recently the __extension__ keyword has been introduced in the kernel.
      Teach genksyms about this keyword so it can generate correct CRC for
      exported symbols that uses a symbol marked __extension__.
      For now only the typedef variant:
      
      	__extension__ typedef ...
      
      is supported.
      Later we may add more variants as needed.
      
      This patch contains the actual source file changes. The
      following patch will hold modifications to the generated
      files (*_shipped) and only after the second patch the fix
      has effect.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3550a516
  9. 21 3月, 2006 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4