Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 6月, 2018 3 次提交
  3. 11 6月, 2018 4 次提交
  5. 08 6月, 2018 6 次提交
  7. 06 6月, 2018 2 次提交
    • G
      staging: lustre: delete the filesystem from the tree. · be65f9ed
      由 Greg Kroah-Hartman 提交于 
      The Lustre filesystem has been in the kernel tree for over 5 years now.
While it has been an endless source of enjoyment for new kernel
developers learning how to do basic codingstyle cleanups, as well as an
semi-entertaining source of bewilderment from the vfs developers any
time they have looked into the codebase to try to figure out how to port
their latest api changes to this filesystem, it has not really moved
forward into the "this is in shape to get out of staging" despite many
half-completed attempts.

And getting code out of staging is the main goal of that portion of the
kernel tree.  Code should not stagnate and it feels like having this
code in staging is only causing the development cycle of the filesystem
to take longer than it should.  There is a whole separate out-of-tree
copy of this codebase where the developers work on it, and then random
changes are thrown over the wall at staging at some later point in time.
This dual-tree development model has never worked, and the state of this
codebase is proof of that.

So, let's just delete the whole mess.  Now the lustre developers can go
off and work in their out-of-tree codebase and not have to worry about
providing valid changelog entries and breaking their patches up into
logical pieces.  They can take the time they have spend doing those
types of housekeeping chores and get the codebase into a much better
shape, and it can be submitted for inclusion into the real part of the
kernel tree when ready.

Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: Andreas Dilger <andreas.dilger@intel.com>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be65f9ed
    • P
      scripts/faddr2line: make the new code listing format optional · 689135f0
      由 Peter Zijlstra (Intel) 提交于 
      Commit 6870c016 ("scripts/faddr2line: show the code context")
radically altered the output format of the faddr2line tool.  And while
the new list output format might have merit it broke my vim usage and
was hard to read.

Make the new format optional; using a '--list' argument and attempt to
make the output slightly easier to read by adding a little whitespace to
separate the different files and explicitly mark the line in question.

Cc: Changbin Du <changbin.du@intel.com>
Fixes: 6870c016 ("scripts/faddr2line: show the code context")
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      689135f0
  9. 05 6月, 2018 4 次提交
  11. 01 6月, 2018 1 次提交
  13. 29 5月, 2018 20 次提交
    • N
      scripts: Fixed printf format mismatch · ac5db1fc
      由 nixiaoming 提交于 
      scripts/kallsyms.c: function write_src:
"printf", the #1 format specifier "d" need arg type "int",
but the according arg "table_cnt" has type "unsigned int"

scripts/recordmcount.c: function do_file:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "(*w2)(ehdr->e_machine)" has type "unsigned int"

scripts/recordmcount.h: function find_secsym_ndx:
"fprintf", the #1 format specifier "d" need arg type "int",
but the according arg "txtndx" has type "unsigned int"
Signed-off-by: Nnixiaoming <nixiaoming@huawei.com>
Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      ac5db1fc
    • M
      kconfig: add basic helper macros to scripts/Kconfig.include · e1cfdc0e
      由 Masahiro Yamada 提交于 
      Kconfig got text processing tools like we see in Make.  Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      e1cfdc0e
    • M
      kconfig: test: add Kconfig macro language tests · 2bece88f
      由 Masahiro Yamada 提交于 
      Here are the test cases I used for developing the text expansion
feature.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      2bece88f
    • M
      kconfig: error out if a recursive variable references itself · 915f6490
      由 Masahiro Yamada 提交于 
      When using a recursively expanded variable, it is a common mistake
to make circular reference.

For example, Make terminates the following code:

  X = $(X)
  Y := $(X)

Let's detect the circular expansion in Kconfig, too.

On the other hand, a function that recurses itself is a commonly-used
programming technique.  So, Make does not check recursion in the
reference with 'call'.  For example, the following code continues
running eternally:

  X = $(call X)
  Y := $(X)

Kconfig allows circular expansion if one or more arguments are given,
but terminates when the same function is recursively invoked 1000 times,
assuming it is a programming mistake.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      915f6490
    • M
      kconfig: add 'filename' and 'lineno' built-in variables · a702a617
      由 Masahiro Yamada 提交于 
      The special variables, $(filename) and $(lineno), are expanded to a
file name and its line number being parsed, respectively.
Suggested-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
      a702a617
    • M
      kconfig: add 'info', 'warning-if', and 'error-if' built-in functions · 1d6272e6
      由 Masahiro Yamada 提交于 
      Syntax:
  $(info,<text>)
  $(warning-if,<condition>,<text>)
  $(error-if,<condition>,<text)

The 'info' function prints a message to stdout as in Make.

The 'warning-if' and 'error-if' are similar to 'warning' and 'error'
in Make, but take the condition parameter.  They are effective only
when the <condition> part is y.

Kconfig does not implement the lazy expansion as used in the 'if'
'and, 'or' functions in Make.  In other words, Kconfig does not
support conditional expansion.  The unconditional 'error' function
would always terminate the parsing, hence would be useless in Kconfig.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
      1d6272e6
    • M
      kconfig: expand lefthand side of assignment statement · 82bc8bd8
      由 Masahiro Yamada 提交于 
      Make expands the lefthand side of assignment statements.  In fact,
Kbuild relies on it since kernel makefiles mostly look like this:

  obj-$(CONFIG_FOO) += foo.o

Do likewise in Kconfig.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      82bc8bd8
    • M
      kconfig: support append assignment operator · ed2a22f2
      由 Masahiro Yamada 提交于 
      Support += operator.  This appends a space and the text on the
righthand side to a variable.

The timing of the evaluation of the righthand side depends on the
flavor of the variable.  If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred.  Appending something to an
undefined variable results in a recursive variable.

To implement this, we need to remember the flavor of variables.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      ed2a22f2
    • M
      kconfig: support simply expanded variable · 1175c025
      由 Masahiro Yamada 提交于 
      The previous commit added variable and user-defined function.  They
work similarly in the sense that the evaluation is deferred until
they are used.

This commit adds another type of variable, simply expanded variable,
as we see in Make.

The := operator defines a simply expanded variable, expanding the
righthand side immediately.  This works like traditional programming
language variables.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1175c025
    • M
      kconfig: support user-defined function and recursively expanded variable · 9ced3bdd
      由 Masahiro Yamada 提交于 
      Now, we got a basic ability to test compiler capability in Kconfig.

config CC_HAS_STACKPROTECTOR
        def_bool $(shell,($(CC) -Werror -fstack-protector -E -x c /dev/null -o /dev/null 2>/dev/null) && echo y || echo n)

This works, but it is ugly to repeat this long boilerplate.

We want to describe like this:

config CC_HAS_STACKPROTECTOR
        bool
        default $(cc-option,-fstack-protector)

It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like that.  Hence, here is another
feature, user-defined function.  This works as a textual shorthand
with parameterization.

A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions.  A user-defined
function in Make is referenced like $(call my-func,arg1,arg2), but I
omitted the 'call' to make the syntax shorter.

The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters.  It is grammatically valid
to pass more or fewer arguments when calling it.  We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.

By the way, a variable is supported as a subset of this feature since
a variable is "a user-defined function with zero argument".  In this
context, I mean "variable" as recursively expanded variable.  I will
add a different flavored variable in the next commit.

The code above can be written as follows:

[Example Code]

  success = $(shell,($(1)) >/dev/null 2>&1 && echo y || echo n)
  cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)

  config CC_HAS_STACKPROTECTOR
          def_bool $(cc-option,-fstack-protector)

[Result]
  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_CC_HAS_STACKPROTECTOR=y
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9ced3bdd
    • M
      kconfig: begin PARAM state only when seeing a command keyword · 9de07153
      由 Masahiro Yamada 提交于 
      Currently, any statement line starts with a keyword with TF_COMMAND
flag.  So, the following three lines are dead code.

        alloc_string(yytext, yyleng);
        zconflval.string = text;
        return T_WORD;

If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.

The next commit will support the assignment statement where a line
starts with an arbitrary identifier.  So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9de07153
    • M
      kconfig: add 'shell' built-in function · 2fd5b09c
      由 Masahiro Yamada 提交于 
      This accepts a single command to execute.  It returns the standard
output from it.

[Example code]

  config HELLO
          string
          default "$(shell,echo hello world)"

  config Y
          def_bool $(shell,echo y)

[Result]

  $ make -s alldefconfig && tail -n 2 .config
  CONFIG_HELLO="hello world"
  CONFIG_Y=y

Caveat:
Like environments, functions are expanded in the lexer.  You cannot
pass symbols to function arguments.  This is a limitation to simplify
the implementation.  I want to avoid the dynamic function evaluation,
which would introduce much more complexity.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      2fd5b09c
    • M
      kconfig: add built-in function support · e298f3b4
      由 Masahiro Yamada 提交于 
      This commit adds a new concept 'function' to do more text processing
in Kconfig.

A function call looks like this:

  $(function,arg1,arg2,arg3,...)

This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      e298f3b4
    • M
      kconfig: make default prompt of mainmenu less specific · 137c0118
      由 Masahiro Yamada 提交于 
      If "mainmenu" is not specified, "Linux Kernel Configuration" is used
as a default prompt.

Given that Kconfig is used in other projects than Linux, let's use
a more generic prompt, "Main menu".
Suggested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      137c0118
    • M
      kconfig: remove sym_expand_string_value() · 5b31a974
      由 Masahiro Yamada 提交于 
      There is no more caller of sym_expand_string_value().
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
      5b31a974
    • M
      kconfig: remove string expansion for mainmenu after yyparse() · 96d8e48d
      由 Masahiro Yamada 提交于 
      Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.

The hack introduced by commit 0724a7c3 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      96d8e48d
    • M
      kconfig: remove string expansion in file_lookup() · bb222cee
      由 Masahiro Yamada 提交于 
      There are two callers of file_lookup(), but there is no more reason
to expand the given path.

[1] zconf_initscan()
    This is used to open the first Kconfig.  sym_expand_string_value()
    has never been used in a useful way here; before opening the first
    Kconfig file, obviously there is no symbol to expand.  If you use
    expand_string_value() instead, environments in KBUILD_KCONFIG would
    be expanded, but I do not see practical benefits for that.

[2] zconf_nextfile()
    This is used to open the next file from 'source' statement.
    Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
    but it was replaced with the direct environment expansion.  The
    environment has already been expanded before the token is passed
    to the parser.

By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
        if (!strcmp(name, file->name)) {
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NUlf Magnusson <ulfalizer@gmail.com>
      bb222cee
    • M
      kconfig: reference environment variables directly and remove 'option env=' · 104daea1
      由 Masahiro Yamada 提交于 
      To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
          string
          default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
      104daea1
    • M
      kbuild: remove kbuild cache · e08d6de4
      由 Masahiro Yamada 提交于 
      The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).

However, this turned out not so clever as I had first expected.
Actually, it is problematic.  For example, "$(CC) -print-file-name"
is cached.  If the compiler is updated, the stale search path causes
build error, which is difficult to figure out.  Another problem
scenario is cache files could be touched while install targets are
running under the root permission.  We can patch them if desired,
but the build infrastructure is getting uglier and uglier.

Now, we are going to move compiler flag tests to the configuration
phase.  If this is completed, the result of compiler tests will be
naturally cached in the .config file.  We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.

To start this work with a cleaner code base, remove the kbuild
cache first.

Revert the following commits:
Commit 9a234a2e ("kbuild: create directory for make cache only when necessary")
Commit e17c400a ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e562071 ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690 ("kbuild: Add a cache for generated variables")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
      e08d6de4
    • A
      trace: Use -mcount-record for dynamic ftrace · 96f60dfa
      由 Andi Kleen 提交于 
      gcc 5 supports a new -mcount-record option to generate ftrace
tables directly. This avoids the need to run record_mcount
manually.

Use this option when available.

So far doesn't use -mcount-nop, which also exists now.

This is needed to make ftrace work with LTO because the
normal record-mcount script doesn't run over the link
time output.

It should also improve build times slightly in the general
case.
Link: http://lkml.kernel.org/r/20171127213423.27218-12-andi@firstfloor.orgSigned-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      96f60dfa