arm: Remove enforced Os flag for LZ4 decompressor

LZ4 has been updated with LZ4 Streaming Format specification(v1.3). lz4demo is replaced by lz4c. lz4c supports both the new streaming and legacy format with -l option.

This patch makes use of lz4c to support legacy format which is used for LZ4 De/compression in the linux kernel.

Link https://code.google.com/p/lz4/source/checkout

Signed-off-by Kyungsik Lee <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Russell King <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Florian Fainelli <[email protected]>

Cc Yann Collet <[email protected]>

Cc Chanho Min <[email protected]>

---
 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

scripts/Makefile.lib +0 -0

index a0ab6d7..c9bfbb0 100644

Quoted 27 lines · Kyungsik Lee

LZ4 has been updated with LZ4 Streaming Format specification(v1.3). lz4demo is replaced by lz4c. lz4c supports both the new streaming and legacy format with -l option.

This patch makes use of lz4c to support legacy format which is used for LZ4 De/compression in the linux kernel.

Link https://code.google.com/p/lz4/source/checkout

Signed-off-by Kyungsik Lee <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Russell King <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Florian Fainelli <[email protected]>

Cc Yann Collet <[email protected]>

Cc Chanho Min <[email protected]>

---
 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

scripts/Makefile.lib +0 -0

index a0ab6d7..c9bfbb0 100644
@@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
 

scripts/Makefile.lib cmd_lzo = (cat $(filter-out FORCE,$^) | \ · line 316

Quoted 4 lines

scripts/Makefile.lib +1 -1

 quiet_cmd_lz4 = LZ4     $@
 cmd_lz4 = (cat $(filter-out FORCE,$^) | \
-     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \

You probably want to check for the presence of lz4c on the system and bail with an informative message if absent.

Quoted 6 lines

Quoted 6 lines

scripts/Makefile.lib +0 -0

index a0ab6d7..c9bfbb0 100644
@@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
 

Quoted 7 lines

scripts/Makefile.lib cmd_lzo = (cat $(filter-out FORCE,$^) | \ · line 316

Quoted 4 lines

scripts/Makefile.lib +1 -1

 quiet_cmd_lz4 = LZ4     $@
 cmd_lz4 = (cat $(filter-out FORCE,$^) | \
-     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \

You probably want to check for the presence of lz4c on the system and bail with an informative message if absent.

Yep, x86_64-randconfig
(http://kisskb.ellerman.id.au/kisskb/buildresult/9110794/):

LZ4 arch/x86/boot/compressed/vmlinux.bin.lz4
/bin/sh: lz4c: command not found

Quoted 14 lines · Geert Uytterhoeven

Quoted 13 lines

scripts/Makefile.lib cmd_lzo = (cat $(filter-out FORCE,$^) | \ · line 316

Quoted 10 lines

scripts/Makefile.lib +1 -1

index a0ab6d7..c9bfbb0 100644
@@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \
 
 quiet_cmd_lz4 = LZ4     $@
 cmd_lz4 = (cat $(filter-out FORCE,$^) | \
-     lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+     lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \

You probably want to check for the presence of lz4c on the system and bail with an informative message if absent.

Quoted 5 lines

Yep, x86_64-randconfig
(http://kisskb.ellerman.id.au/kisskb/buildresult/9110794/):

LZ4 arch/x86/boot/compressed/vmlinux.bin.lz4
/bin/sh: lz4c: command not found

Sure, it had to be 2 months and to hit upstream for there still to be no fix. Geez...

Well, there's also no hand-holding when lzop is missing for LZO. And the error message is clear enough. No?

BTW speaking of introductory-level patches, what about the following one:

Now that lz4 kernel compression is available, add *.lz4 to .gitignore

BTW speaking of introductory-level patches, what about the following one:

Now that lz4 kernel compression is available, add *.lz4 to .gitignore

.gitignore +0 -0

index 3b8b9b3..7e9932e 100644

LZ4 has been updated with LZ4 Streaming Format specification(v1.3). lz4demo is replaced by lz4c. lz4c supports both the new streaming and legacy format with -l option.

This patch makes use of lz4c to support legacy format which is used for LZ4 De/compression in the linux kernel.

Link https://code.google.com/p/lz4/source/checkout

Signed-off-by Kyungsik Lee <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Russell King <[email protected]>

Cc Borislav Petkov <[email protected]>

Cc Florian Fainelli <[email protected]>

Cc Yann Collet <[email protected]>

Cc Chanho Min <[email protected]>

---
 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

scripts/Makefile.lib +0 -0

index a0ab6d7..c9bfbb0 100644

If a utility is not widely available yet and if the utility is not in the kernel proper, could you please at least make sure that randconfig does not stumble over non-buildable kernels?

Quoted 4 lines · Ingo Molnar

If a utility is not widely available yet and if the utility is not in the kernel proper, could you please at least make sure that randconfig does not stumble over non-buildable kernels?

Two months ago I've complained about this and other people have burned themselves too in the meantime...

and now it is upstream already, via -mm:

e76e1fdfa8f8 lib: add support for LZ4-compressed kernel

Quoted 3 lines · Ingo Molnar

and now it is upstream already, via -mm:

e76e1fdfa8f8 lib: add support for LZ4-compressed kernel

Sure. Let's see if it manages to get released b0rked like it is right now.

Quoted 7 lines · On Fri, 12 Jul 2013 12:23:26 +0200 Borislav Petkov <[email protected]> wrote:

Quoted 3 lines · Ingo Molnar

and now it is upstream already, via -mm:

e76e1fdfa8f8 lib: add support for LZ4-compressed kernel

Sure. Let's see if it manages to get released b0rked like it is right now.

Well y'know, if whining fixed bugs then there would be no problem here at all.

This problem came up briefly and I thought it had been adequately addressed. Now a month or two later we find out who are the people who can't be bothered testing -next, but think it terribly important that others do so.

Well y'know, if whining fixed bugs then there would be no problem here at all.

This problem came up briefly and I thought it had been adequately addressed. Now a month or two later we find out who are the people who can't be bothered testing -next, but think it terribly important that others do so.

Quoted 2 lines

Well y'know, if whining fixed bugs then there would be no problem here at all.

I know. I decided to whine this time and not try to fix it because attempting to fix every fallout I'm seeing in the tree with randconfigs is a full-time job and the *actual* job doesn't see any progress.

And in all fairness, if someone were reporting an issue against my code, I'll try to do my very best to fix it as quickly aas possible, instead of ignoring it.

So actually, the right thing to do in such cases is back out half-cooked stuff from the tree until it gets fixed. That'll give the authors the right incentive. But this is just me.

Quoted 4 lines

This problem came up briefly and I thought it had been adequately addressed. Now a month or two later we find out who are the people who can't be bothered testing -next, but think it terribly important that others do so.

Yeah, if everyone would put their money where their mouth is...

Shall we provide a shell script wrapper for all of these compressor commands which would test for the utility presence and issue a BIG FAT WARNING if not, but still create the file not to make the kernel build fail? I guess we could probably do this in the Makefile directly as well.

scripts/Makefile.lib cmd_lzo = (cat $(filter-out FORCE,$^) | \ · line 317

Quoted 5 lines · Kyungsik Lee

quiet_cmd_lz4 = LZ4 $@
cmd_lz4 = (cat $(filter-out FORCE,$^) | \

scripts/Makefile.lib +1 -1

-	lz4demo -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
+	lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
 	(rm -f $@ ; false)

None of the major distros I tried has the lz4 or lz4c binary available, and this breaks randconfig builds:

/bin/sh: lz4c: command not found

If:

CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_LZ4=y
CONFIG_RD_LZ4=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_DECOMPRESS_LZ4=y

If a utility is not widely available yet and if the utility is not in the kernel proper, could you please at least make sure that randconfig does not stumble over non-buildable kernels?

I don't know how to do this. Any suggestions?

It has to be done at `make config' time. We'd need to probe for the presence of lz4c and then.... what?

Is there any precedent for this?

I don't think we can just ignore the absence of lz4c - the user has selected a config which his system cannot build. The problem lies within randconfig itself.

Quoted 8 lines · Andrew Morton

I don't know how to do this. Any suggestions?

It has to be done at `make config' time. We'd need to probe for the presence of lz4c and then.... what?

Is there any precedent for this?

Quoted 4 lines

I don't think we can just ignore the absence of lz4c - the user has selected a config which his system cannot build. The problem lies within randconfig itself.

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Quoted 9 lines · On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <[email protected]> wrote:

Quoted 8 lines · Andrew Morton

I don't know how to do this. Any suggestions?

It has to be done at `make config' time. We'd need to probe for the presence of lz4c and then.... what?

Is there any precedent for this?

Quoted 9 lines

Quoted 4 lines

I don't think we can just ignore the absence of lz4c - the user has selected a config which his system cannot build. The problem lies within randconfig itself.

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Would it make sense to extend Kconfig's `depends'?

	depends on $(shell-command)

I don't know how practical that would be to implement...

Quoted 2 lines · On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <[email protected]>…

Quoted 1 line · On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <[email protected]> wrote:

On 07/15/2013 03:03 PM, Andrew Morton wrote:

Quoted 10 lines

Quoted 4 lines

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Would it make sense to extend Kconfig's `depends'?

	depends on $(shell-command)

I don't know how practical that would be to implement...

Or, easier and faster, run some front-end script which generates once-off Kconfig symbols.

	if [ -x /bin/lz4c ]
	then
		echo CONFIG_HAVE_LZ4C
	fi

then munge the output of that script into the Kconfig run and do

depends on HAVE_LZ4C

Quoted 11 lines

Or, easier and faster, run some front-end script which generates once-off Kconfig symbols.

	if [ -x /bin/lz4c ]
	then
		echo CONFIG_HAVE_LZ4C
	fi

then munge the output of that script into the Kconfig run and do

depends on HAVE_LZ4C

Yes, this is a better solution.

For what it's worth, this is what I'm doing in crosstool-NG: a script checks for optional pre-requisites, spits out a Kconfig blob which is included by the top-level Kconfig file.

Here is a snippet of generated Kconfig blob:
config HAVE_XZ
def_bool y
config HAVE_LZMA
bool

Which means we do have 'xz', but not 'lzma'. This is relatively trivial to do, so I'll tackle this this evening when I'm back home (unless someone beats me to it).

What I'm angling at is, rather than a single global front-end script, can we embed the scripts in some fashion within the various Kconfig files? Say,

script ./some-script.sh

and the config system will only evaluate that command if it is working on that Kconfig file. Obviously that requires a multiple-pass thing.

Quoted 4 lines · Andrew Morton

What I'm angling at is, rather than a single global front-end script, can we embed the scripts in some fashion within the various Kconfig files? Say,

Quoted 4 lines

script ./some-script.sh

and the config system will only evaluate that command if it is working on that Kconfig file. Obviously that requires a multiple-pass thing.

What's wrong with simply grepping the .config we've just created for *enabled* symbols which require userspace support, check for the presence of said support and bail out if none?

I.e., those steps:
1. make <whatever>config
2. make => A prereq. target runs the shell script.

The goal is to avoid generating a non-buildable kernel in the first place.

Quoted 3 lines

I.e., those steps:
1. make <whatever>config
2. make => A prereq. target runs the shell script.

This is too late, since this will bail out, and will give a false-positive failure.

While if we were to check for _known_ needed tools before calling into Kconfig,

Quoted 1 line · Yann E. MORIN

The goal is to avoid generating a non-buildable kernel in the first place.

I know, that's why I'm proposing to fail the build with the script run as one of the first things by make.

Quoted 4 lines

Quoted 3 lines

I.e., those steps:
1. make <whatever>config
2. make => A prereq. target runs the shell script.

Quoted 2 lines

This is too late, since this will bail out, and will give a false-positive failure.

Huh? This will tell you: "you've selected X, but I don't have toolX needed for the build".

You install the tool and run make again. Checks pass, the build continues.

Quoted 2 lines

While if we were to check for _known_ needed tools before calling into Kconfig,

How would you do that? How do you know what the user is going to select *before* she even selects it?

You need to have a prepared .config to act upon.

No, this is already too late: the given .config *is* already broken and unbuildable.

That does not work in two cases:
- older distros that do not have the tool packaged

- automatic test-harness that run thousands of randconfig a day

The idea is to be always have a .config that is buildable with the current toolset of the system, especially for esoteric and/or recent tools that are not packaged and/or installed by default by the distros.

Quoted 2 lines · Yann E. MORIN

That does not work in two cases:
- older distros that do not have the tool packaged

This point is moot - distro kernels are built by the distro people.

Quoted 1 line

- automatic test-harness that run thousands of randconfig a day

randconfigs are not guaranteed to build successfully.

Quoted 4 lines

The idea is to be always have a .config that is buildable with the current toolset of the system, especially for esoteric and/or recent tools that are not packaged and/or installed by default by the distros.

How are you going to tell the user running make <something>config to install the missing tools?

As discussed with Florian in this thread, either one of:
- a warning at check time
- a comment in Kconfig

Quoted 3 lines

As discussed with Florian in this thread, either one of:
- a warning at check time
- a comment in Kconfig

Whatever you do, make sure to make it quite clear to users what she needs to do.

What I really have a problem with is options being hidden just because I haven't selected something they depend on and having to run around the Kconfig maze to find what I also need to select in order for the option to appear.

Andrew, All,

Quoted 3 lines · On Tuesday 16 July 2013 09:56:11 Andrew Morton wrote:

Quoted 2 lines · On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <[email protected]>…

Quoted 1 line · On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <[email protected]> wrote:

On 07/15/2013 03:03 PM, Andrew Morton wrote:

[--SNIP--]

Quoted 10 lines

Quoted 10 lines

Quoted 4 lines

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Would it make sense to extend Kconfig's `depends'?

	depends on $(shell-command)

I don't know how practical that would be to implement...

I'm afraid this will get rather ugly and not trivial.

Can we mix 'depends on SYMBOL' and 'depends on $(command)' ? Can we mix both in a boolean expression such as 'depends on SYMBOL && $(command)' ?

What would be the condition for evaluating the dependency rule? Evaluation at Kconfig read-time might not be enough, given this construct:

    config FOO
        depends on $(foo)
    comment "'foo' is missing, please install it"
        depends on !$(foo)

Also, I believe Kconfig should stay a config-only language, without much esoteric features.

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import external values.

The drawback I see with this approach is that we may execute a lot of small programs where the value is never used.

scripts/kconfig/symbol.c +25 -0

+
+			/* Drop any trialing newlines */
+			i = strlen(buffer);
+			while (i > 0 && buffer[i - 1] == '\n') {
+				buffer[i - 1] = '\0';
+				i--;
+			}
+			/* Validate the output of the command */
+			if (strlen(buffer) == 0) {
+				menu_warn(current_entry,
+				          "command '%s' - invalid (empty?) return value: \"%s\"",
+				          command, buffer);
+				return;
+			}
+
+			menu_warn(current_entry, "default: %s", buffer);
+			sym_add_default(sym, buffer);
+		} else {
+			menu_warn(current_entry, "command '%s' - empty return value", command);
+		}
+		pclose(stream);
+	} else {
+		menu_warn(current_entry, "command '%s' failed to execute", command);
+	}
+}

Quoted 7 lines

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

Quoted 8 lines

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import external values.

The drawback I see with this approach is that we may execute a lot of small programs where the value is never used.

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

I have tested this lightly - as we should discuss if this is a viable way forward.

For now I used popen() - so return value of the executed program are ignored.

scripts/kconfig/symbol.c +16 -0

@@ -1379,3 +1381,56 @@ static void prop_add_env(const char *env)
 	else
 		menu_warn(current_entry, "environment variable %s undefined", env);
 }
+
+static void exec_command(const char *command, struct symbol *sym)
+{
+	char buffer[2048];
+	FILE *stream;
+
+	stream = popen(command, "r");
+
+	if (stream != NULL) {
+		if (fgets(buffer, sizeof(buffer), stream) != NULL) {
+			int i;
+
+			buffer[sizeof(buffer) - 1] = '\0';
+
+			/* Drop any trialing newlines */
+			i = strlen(buffer);

At the very least we'd have to decide if this is available only for booleans/tristates, or for any type? Your implementation seems to make it valid for strings/ints, too.

It is worth noting that one of the things that keep getting brought up as something that need this is gcc/binutils support for a specific feature.

On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:

Quoted 16 lines

Quoted 7 lines

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

Quoted 8 lines

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import external values.

The drawback I see with this approach is that we may execute a lot of small programs where the value is never used.

Quoted 6 lines

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

make REGENERATE_PARSERS=y menuconfig

Quoted 1 line

I have tested this lightly - as we should discuss if this is a viable way forward.

Instead of extending the Kconfig language, I was thinking (as initially suggested by Andrew) of generating a Kconfig file before all config targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

Quoted 28 lines · Yann E. MORIN

On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:

Quoted 16 lines

Quoted 7 lines

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

Quoted 8 lines

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import external values.

The drawback I see with this approach is that we may execute a lot of small programs where the value is never used.

Quoted 6 lines

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

make REGENERATE_PARSERS=y menuconfig

Quoted 1 line

I have tested this lightly - as we should discuss if this is a viable way forward.

Quoted 3 lines

Instead of extending the Kconfig language, I was thinking (as initially suggested by Andrew) of generating a Kconfig file before all config targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

I also prefer the generated Kconfig file.
It keeps all these checks in a single place, instead of spreading it over all Kconfig files. This allows to keep better control over the list of checks, and notice when it gets out-of-hand.

Quoted 29 lines · On Thu, 18 Jul 2013 09:22:58 +0200 Geert Uytterhoeven <[email protected]>…

Quoted 27 lines · Yann E. MORIN

On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:

Quoted 10 lines

Quoted 10 lines

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

Quoted 8 lines

Quoted 2 lines

This only extendt Kconfig slightly - using an already present method to import external values.

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

make REGENERATE_PARSERS=y menuconfig

Quoted 1 line

I have tested this lightly - as we should discuss if this is a viable way forward.

Instead of extending the Kconfig language, I was thinking (as initially suggested by Andrew) of generating a Kconfig file before all config targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

Quoted 4 lines

I also prefer the generated Kconfig file.
It keeps all these checks in a single place, instead of spreading it over all Kconfig files. This allows to keep better control over the list of checks, and notice when it gets out-of-hand.

I prefer the "option exec" approach, actually. That way the shell-outs are colocated with the code which uses

them and they will only be executed
if you've actually selected that subsystem for building (I think?).

Quoted 3 lines

I prefer the "option exec" approach, actually. That way the shell-outs are colocated with the code which uses

Indeed, but in this case, all the checks will be spread-out in the Kconfig files, and not easily locatable. Having all in a single script will also more easily raise eyebrows when that script appears in a diffstat. Noticing the 'exec' option risks being a bit less easy.

But, that's not my call to decide. ;-)

Quoted 2 lines

them and they will only be executed
if you've actually selected that subsystem for building (I think?).

If I understand the code correctly (which is still to be proven), the exec option is run at parse-time, once.

Sam, All,

Well, while I was fighting on this on my side... ;-)

On 2013-07-17 23:16 +0200, Sam Ravnborg spake thusly:

Quoted 16 lines

Quoted 15 lines

We could extend the symbol option part to retreive values from a binary. Something like this:

config FOOBAR
bool
option exec="true"

FOOBAR would assume the value "y" if the command true has exit code == 0, otherwise "n". And similar conversions for other types.

This only extendt Kconfig slightly - using an already present method to import external values.

The drawback I see with this approach is that we may execute a lot of small programs where the value is never used.

Quoted 6 lines

Following is a quick patch implmenting this idea.
You need to run gperf manually to enable this.

"gperf -C scripts/kconfig/zconf.gperf > scripts/kconfig/zconf.hash.c"

I did not figure out how to use the built-in rules to generate this file :-(

make REGENERATE_PARSERS=y menuconfig

Quoted 2 lines

I have tested this lightly - as we should discuss if this is a viable way forward.

Instead of extending the Kconfig language, I was thinking (as initially suggested by Andrew) of generating a Kconfig file before all config targets, and source that Kconfig file from $(TOPDIR)/Kconfig.

I'm not a fan od extending the Kconfig language in this way. It feels weird to me. Especially when we have a way to solve this specific issue with a script that generates the needed Kconfig symbols before any config target is called.

Quoted 22 lines · On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <[email protected]> wrote:

Quoted 10 lines · Andrew Morton

Quoted 8 lines

I don't know how to do this. Any suggestions?

It has to be done at `make config' time. We'd need to probe for the presence of lz4c and then.... what?

Is there any precedent for this?

Quoted 9 lines

Quoted 4 lines

I don't think we can just ignore the absence of lz4c - the user has selected a config which his system cannot build. The problem lies within randconfig itself.

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Quoted 5 lines

Would it make sense to extend Kconfig's `depends'?

      depends on $(shell-command)

I don't know how practical that would be to implement...

Or, easier and faster, run some front-end script which generates once-off Kconfig symbols.

        if [ -x /bin/lz4c ]
        then
                echo CONFIG_HAVE_LZ4C
        fi

then munge the output of that script into the Kconfig run and do

depends on HAVE_LZ4C

2013/7/16 Andrew Morton <[email protected]>:

Quoted 37 lines · On Tue, 16 Jul 2013 00:47:27 -0700 Andrew Morton <[email protected]>…

Quoted 22 lines · On Mon, 15 Jul 2013 15:08:20 -0700 "H. Peter Anvin" <[email protected]> wrote:

Quoted 10 lines · Andrew Morton

Quoted 8 lines

I don't know how to do this. Any suggestions?

It has to be done at `make config' time. We'd need to probe for the presence of lz4c and then.... what?

Is there any precedent for this?

Quoted 9 lines

Quoted 4 lines

I don't think we can just ignore the absence of lz4c - the user has selected a config which his system cannot build. The problem lies within randconfig itself.

We keep running over the need to be able to have kconfig run tests on the build system (for toolchain support or for optional tools needed); running them in the Makefiles (i.e. at Kbuild time) is simply too late.

Quoted 5 lines

Would it make sense to extend Kconfig's `depends'?

      depends on $(shell-command)

I don't know how practical that would be to implement...

Or, easier and faster, run some front-end script which generates once-off Kconfig symbols.

        if [ -x /bin/lz4c ]
        then
                echo CONFIG_HAVE_LZ4C
        fi

Quoted 3 lines

then munge the output of that script into the Kconfig run and do

depends on HAVE_LZ4C

That does sound nice to avoid the build error, but will eventually make it harder to diagnose why the kernel has not been compressed with the specific compression tool, some kind of warning should also be emitted maybe?