On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
wrote:
> [Major Changes in V3]
Awesome work! I don't see this pushed to your git tree? I'd like to
test it, but I'd rather "git fetch" instead of "git am" :)
-Kees
--
Kees Cook
Pixel Security
On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
wrote:
> [Major Changes in V3]
Awesome work! I don't see this pushed to your git tree? I'd like to
test it, but I'd rather "git fetch" instead of "git am" :)
-Kees
--
Kees Cook
Pixel Security
2018-04-01 15:05 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC
2018-04-01 15:05 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null
>> -o
On 13 April 2018 at 11:39, Vinod Koul wrote:
> On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote:
>
>> >> > what does block and transaction len refer to here
>> >>
>> >> Our DMA has 3 transfer mode: transaction transfer, block transfer and
>> >> fragment transfer.
On 13 April 2018 at 11:39, Vinod Koul wrote:
> On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote:
>
>> >> > what does block and transaction len refer to here
>> >>
>> >> Our DMA has 3 transfer mode: transaction transfer, block transfer and
>> >> fragment transfer. One transaction
Hi, Eduardo,
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui
> > wrote:
> > >
> > >
> > > could you please illustrate me what the
Hi, Eduardo,
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui
> > wrote:
> > >
> > >
> > > could you please illustrate me what the kconfig & warning is?
>
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o:
Hi Theodore,
> The crng_init variable has three states:
>
> 0: The CRNG is not initialized at all
> 1: The CRNG has a small amount of entropy, hopefully good enough for
>early-boot, non-cryptographical use cases
> 2: The CRNG
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o:
Hi Theodore,
> The crng_init variable has three states:
>
> 0: The CRNG is not initialized at all
> 1: The CRNG has a small amount of entropy, hopefully good enough for
>early-boot, non-cryptographical use cases
> 2: The CRNG
2018-04-01 13:19 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>
2018-04-01 13:19 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>> $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this
2018-03-28 12:41 GMT+09:00 Kees Cook :
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>
2018-03-28 12:41 GMT+09:00 Kees Cook :
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>> $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui
> > wrote:
> > >
> > >
> > > could you please illustrate me what the kconfig & warning
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui
> > wrote:
> > >
> > >
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make
The __current_kernel_time() function based on 'struct timespec' is no
longer recommended for new code, and the only user of this function
has been replaced by commit 6909e29fdefb ("kdb: use
__ktime_get_real_seconds instead of __current_kernel_time"). So now we
can remove this obsolete interface.
The __current_kernel_time() function based on 'struct timespec' is no
longer recommended for new code, and the only user of this function
has been replaced by commit 6909e29fdefb ("kdb: use
__ktime_get_real_seconds instead of __current_kernel_time"). So now we
can remove this obsolete interface.
Hi Guenter,
Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :
> Hi all,
> we are observing crashes with z3pool under memory pressure. The kernel
version
> used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
problem was
> also seen with v4.14 based kernels.
Hi Guenter,
Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :
> Hi all,
> we are observing crashes with z3pool under memory pressure. The kernel
version
> used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
problem was
> also seen with v4.14 based kernels.
just before I dig
2018-04-13 14:06 GMT+09:00 Masahiro Yamada :
I forgot to prefix the patch subjects with the version.
This series is V3.
> [Introduction]
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile. A number of kernel
2018-04-13 14:06 GMT+09:00 Masahiro Yamada :
I forgot to prefix the patch subjects with the version.
This series is V3.
> [Introduction]
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile. A number of kernel features require the
> compiler
From: Greg Hartman
The cuttlefish system is a virtual SoC architecture based on QEMU. It
uses the QEMU ivshmem feature to share memory regions between guest and
host with a custom protocol.
Cc: Greg Kroah-Hartman
Cc: Arve Hjønnevåg
From: Greg Hartman
The cuttlefish system is a virtual SoC architecture based on QEMU. It
uses the QEMU ivshmem feature to share memory regions between guest and
host with a custom protocol.
Cc: Greg Kroah-Hartman
Cc: Arve Hjønnevåg
Cc: Todd Kjos
Cc: Martijn Coenen
Cc: Dan Carpenter
Cc:
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
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
Here are the test cases I used for developing the text expansion
feature.
I implemented a similar language as you see in Make. The implementation
is different (the source code in GNU Make is much longer, so I did not
want to pull it in), but the behavior is hopefully almost the same.
I
Here are the test cases I used for developing the text expansion
feature.
I implemented a similar language as you see in Make. The implementation
is different (the source code in GNU Make is much longer, so I did not
want to pull it in), but the behavior is hopefully almost the same.
I
[Introduction]
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles. If a chosen
feature turns
Add a document for the macro language introduced to Kconfig.
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time
[Introduction]
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles. If a chosen
feature turns
Add a document for the macro language introduced to Kconfig.
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time
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,
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,
The kernel configuration phase is now tightly coupled with the compiler
in use. It will be nice to show the compiler information in Kconfig.
The compiler information will be displayed like this:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
scripts/kconfig/conf --oldaskconfig
The kernel configuration phase is now tightly coupled with the compiler
in use. It will be nice to show the compiler information in Kconfig.
The compiler information will be displayed like this:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
scripts/kconfig/conf --oldaskconfig
This will be useful to specify the required compiler version,
like this:
config FOO
bool "Use Foo"
depends on GCC_VERSION >= 408000
help
This feature requires GCC 4.8 or newer.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
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: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf
This will be useful to specify the required compiler version,
like this:
config FOO
bool "Use Foo"
depends on GCC_VERSION >= 408000
help
This feature requires GCC 4.8 or newer.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v3: None
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: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v3:
- Move helpers to
This will be useful to describe the clang version dependency.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
init/Kconfig | 7 +++
scripts/clang-version.sh | 18
This will be useful to describe the clang version dependency.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
init/Kconfig | 7 +++
scripts/clang-version.sh | 18 --
2 files changed, 11 insertions(+), 14
Add 'info' and 'warning' functions as in Make.
They print messages during parsing Kconfig files, which is useful
when debugging Kconfig at least.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 28
Kbuild provides a couple of ways to specify CROSS_COMPILE:
[1] Command line
[2] Environment
[3] arch/*/Makefile (only some architectures)
[4] CONFIG_CROSS_COMPILE
[4] is problematic for the compiler capability tests in Kconfig.
CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
Add 'info' and 'warning' functions as in Make.
They print messages during parsing Kconfig files, which is useful
when debugging Kconfig at least.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 28
1 file
Kbuild provides a couple of ways to specify CROSS_COMPILE:
[1] Command line
[2] Environment
[3] arch/*/Makefile (only some architectures)
[4] CONFIG_CROSS_COMPILE
[4] is problematic for the compiler capability tests in Kconfig.
CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
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: Masahiro
Run scripts/gcc-plugin.sh from Kconfig so that users can enable
GCC_PLUGINS only when the compiler supports building plugins.
Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain
the compiler (g++ or gcc) used for building plugins, or empty
if the plugin can not be supported at all.
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: Masahiro
Run scripts/gcc-plugin.sh from Kconfig so that users can enable
GCC_PLUGINS only when the compiler supports building plugins.
Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain
the compiler (g++ or gcc) used for building plugins, or empty
if the plugin can not be supported at all.
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.
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.
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly
Since commit d677a4d60193 ("Makefile: support flag
-fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV
plugin under some circumstances.
CONFIG_KCOV=y
CONFIG_KCOV_ENABLE_COMPARISONS=y
Your compiler does not support -fsanitize-coverage=trace-pc
Your compiler does not support
Since commit d677a4d60193 ("Makefile: support flag
-fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV
plugin under some circumstances.
CONFIG_KCOV=y
CONFIG_KCOV_ENABLE_COMPARISONS=y
Your compiler does not support -fsanitize-coverage=trace-pc
Your compiler does not support
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
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
Now, we got a basic ability to test compiler capability in Kconfig.
config CC_HAS_STACKPROTECTOR
def_bool $(shell (($(CC) -Werror -fstack-protector -c -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
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
Now, we got a basic ability to test compiler capability in Kconfig.
config CC_HAS_STACKPROTECTOR
def_bool $(shell (($(CC) -Werror -fstack-protector -c -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
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
There is no more caller of sym_expand_string_value().
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 -
scripts/kconfig/symbol.c| 53 -
2
There is no more caller of sym_expand_string_value().
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 -
scripts/kconfig/symbol.c| 53 -
2 files changed, 54 deletions(-)
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the
version check to Kconfig so that the GCC plugin menus will be hidden
if an older compiler is in use.
Signed-off-by: Masahiro Yamada
Acked-by: Andrew Donnellan
---
For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the
version check to Kconfig so that the GCC plugin menus will be hidden
if an older compiler is in use.
Signed-off-by: Masahiro Yamada
Acked-by: Andrew Donnellan
---
Changes in v3:
- Move comment to Kconfig as well
Changes in
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.
Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
'depends on !COMPILE_TEST' for the following three are still kept:
GCC_PLUGIN_CYC_COMPLEXITY
GCC_PLUGIN_STRUCTLEAK_VERBOSE
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.
Now
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.
Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
'depends on !COMPILE_TEST' for the following three are still kept:
GCC_PLUGIN_CYC_COMPLEXITY
GCC_PLUGIN_STRUCTLEAK_VERBOSE
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.
Now
This config option should be enabled only when both the compiler and
the linker support necessary flags. Add proper dependencies to Kconfig.
Unlike 'select', 'imply' is modest enough to observe those dependencies.
I suggested this in the help message.
Signed-off-by: Masahiro Yamada
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c
according to your GCC version.
We can achieve the equivalent behavior by setting reasonable dependency
with the knowledge of the compiler version.
If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users
are
This config option should be enabled only when both the compiler and
the linker support necessary flags. Add proper dependencies to Kconfig.
Unlike 'select', 'imply' is modest enough to observe those dependencies.
I suggested this in the help message.
Signed-off-by: Masahiro Yamada
---
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c
according to your GCC version.
We can achieve the equivalent behavior by setting reasonable dependency
with the knowledge of the compiler version.
If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users
are
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
This becomes much neater in Kconfig.
Signed-off-by: Masahiro Yamada
Acked-by: Will Deacon
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 2 --
2
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
This becomes much neater in Kconfig.
Signed-off-by: Masahiro Yamada
Acked-by: Will Deacon
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git
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
Make allows variable references in the lefthand side of assignment.
X = A
Y = B
$(X)$(Y) = 1
This does 'AB = 1' Do likewise in Kconfig as well.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 7
Now that 'shell' function is supported, this can be self-contained in
Kconfig.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v3: None
Changes in v2: None
Makefile
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
Make allows variable references in the lefthand side of assignment.
X = A
Y = B
$(X)$(Y) = 1
This does 'AB = 1' Do likewise in Kconfig as well.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 7 +++
1 file changed, 7
Now that 'shell' function is supported, this can be self-contained in
Kconfig.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v3: None
Changes in v2: None
Makefile | 3 +--
init/Kconfig | 4 ++--
2 files changed, 3 insertions(+), 4
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s
On 2018年04月01日 22:12, Tiwei Bie wrote:
Hello everyone,
This RFC implements packed ring support for virtio driver.
The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost
On 2018年04月01日 22:12, Tiwei Bie wrote:
Hello everyone,
This RFC implements packed ring support for virtio driver.
The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost
> Do you have a target date for posting that?
Yes, we have the target date. We will submit WhiteEgret v4 by September.
> So you have a design for being able to differentiate the interpreters
> reading versus reading with the intent to execute?
> With or without their help?
We will provide WEUA
> Do you have a target date for posting that?
Yes, we have the target date. We will submit WhiteEgret v4 by September.
> So you have a design for being able to differentiate the interpreters
> reading versus reading with the intent to execute?
> With or without their help?
We will provide WEUA
Hello,
On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui wrote:
> >
> > could you please illustrate me what the kconfig & warning is?
>
> Just "make allmodconfig" and the warning is about a uninitialized variable.
Hello,
On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui wrote:
> >
> > could you please illustrate me what the kconfig & warning is?
>
> Just "make allmodconfig" and the warning is about a uninitialized variable.
>
> Line 304 in
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:06, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> On 2018/4/10 12:10, Jaegeuk Kim wrote:
> >>> On 04/10, Chao Yu wrote:
> On 2018/4/10 2:02, Jaegeuk Kim wrote:
> > On 04/08, Chao Yu wrote:
> >> On 2018/4/5 11:51, Jaegeuk Kim wrote:
>
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:06, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> On 2018/4/10 12:10, Jaegeuk Kim wrote:
> >>> On 04/10, Chao Yu wrote:
> On 2018/4/10 2:02, Jaegeuk Kim wrote:
> > On 04/08, Chao Yu wrote:
> >> On 2018/4/5 11:51, Jaegeuk Kim wrote:
>
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:04, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/4/8 16:13, Chao Yu wrote:
> >>> f2fs doesn't allow abuse on atomic write class interface, so except
> >>> limiting in-mem pages' total memory usage capacity, we need to
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:04, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/4/8 16:13, Chao Yu wrote:
> >>> f2fs doesn't allow abuse on atomic write class interface, so except
> >>> limiting in-mem pages' total memory usage capacity, we need to
1 - 100 of 1552 matches
Mail list logo