Cloneconfig takes the first configuration it finds which appears
to belong to the running kernel, and configures the kernel sources
to match this configuration as closely as possible.
Signed-off-by: Andreas Gruenbacher <[email protected]>
Signed-off-by: Jeff Mahoney <[email protected]>
---
scripts/kconfig/Makefile | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -99,6 +99,23 @@ PHONY += allnoconfig allyesconfig allmod
allnoconfig allyesconfig allmodconfig alldefconfig randconfig: $(obj)/conf
$< --$@ $(Kconfig)
+
+UNAME_RELEASE := $(shell uname -r)
+CLONECONFIG := $(firstword $(wildcard /proc/config.gz \
+ /lib/modules/$(UNAME_RELEASE)/.config \
+ /etc/kernel-config \
+ /boot/config-$(UNAME_RELEASE)))
+cloneconfig: $(obj)/conf
+ $(Q)case "$(CLONECONFIG)" in \
+ '') echo -e "The configuration of the running" \
+ "kernel could not be determined\n"; \
+ false ;; \
+ *.gz) gzip -cd $(CLONECONFIG) > .config.running ;; \
+ *) cat $(CLONECONFIG) > .config.running ;; \
+ esac && \
+ echo -e "Cloning configuration file $(CLONECONFIG)\n"
+ $(Q)$< -D .config.running arch/$(SRCARCH)/Kconfig
+
PHONY += listnewconfig oldnoconfig savedefconfig defconfig
--
Jeff Mahoney
SUSE Labs
On Thu, Feb 24, 2011 at 09:35:02PM -0500, Jeff Mahoney wrote:
> Cloneconfig takes the first configuration it finds which appears
> to belong to the running kernel, and configures the kernel sources
> to match this configuration as closely as possible.
>
> Signed-off-by: Andreas Gruenbacher <[email protected]>
> Signed-off-by: Jeff Mahoney <[email protected]>
> ---
> scripts/kconfig/Makefile | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -99,6 +99,23 @@ PHONY += allnoconfig allyesconfig allmod
>
> allnoconfig allyesconfig allmodconfig alldefconfig randconfig: $(obj)/conf
> $< --$@ $(Kconfig)
> +
> +UNAME_RELEASE := $(shell uname -r)
> +CLONECONFIG := $(firstword $(wildcard /proc/config.gz \
> + /lib/modules/$(UNAME_RELEASE)/.config \
> + /etc/kernel-config \
> + /boot/config-$(UNAME_RELEASE)))
> +cloneconfig: $(obj)/conf
> + $(Q)case "$(CLONECONFIG)" in \
> + '') echo -e "The configuration of the running" \
> + "kernel could not be determined\n"; \
> + false ;; \
> + *.gz) gzip -cd $(CLONECONFIG) > .config.running ;; \
> + *) cat $(CLONECONFIG) > .config.running ;; \
> + esac && \
> + echo -e "Cloning configuration file $(CLONECONFIG)\n"
> + $(Q)$< -D .config.running arch/$(SRCARCH)/Kconfig
> +
We already have something remotely similar in kconfig.
We use the following list:
config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
default "/lib/modules/$UNAME_RELEASE/.config"
default "/etc/kernel-config"
default "/boot/config-$UNAME_RELEASE"
default "$ARCH_DEFCONFIG"
default "arch/$ARCH/defconfig"
It would be better to teach kconfig to read /proc/config.gz
and then add it to the list above.
This list is used if you just type "make enuconfig" without
any configuration.
Sam
This patch adds type handlers for compressed config files. Initial
support provides callouts for gzip and bzip2, but there's no reason
others could be added if demand is there.
This is intended to allow /proc/config.gz be a configuration source
for 'make oldconfig' when .config is absent.
Signed-off-by: Jeff Mahoney <[email protected]>
---
scripts/kconfig/zconf.l | 50 ++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 48 insertions(+), 2 deletions(-)
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -256,6 +256,44 @@ static void zconf_endhelp(void)
BEGIN(INITIAL);
}
+static const struct type_handler {
+ const char *suffix;
+ const char *command;
+} type_handlers[] = {
+ {
+ .suffix = ".gz",
+ .command = "zcat",
+ },
+ {
+ .suffix = ".bz2",
+ .command = "bzcat",
+ },
+ /* Whatever other algorithms you like */
+ {}
+};
+
+static const struct type_handler *get_type_handler(const char *name)
+{
+ char *p = rindex(name, '.');
+ if (p) {
+ const struct type_handler *ops = type_handlers;
+ for (ops = type_handlers; ops->suffix; ops++) {
+ if (!strcasecmp(ops->suffix, p))
+ break;
+ }
+ if (!ops->suffix)
+ return NULL;
+ return ops;
+ }
+ return NULL;
+}
+
+static FILE *zconf_popen(const char *command, const char *name)
+{
+ char cmdbuf[PATH_MAX + strlen(command) + 2];
+ snprintf(cmdbuf, sizeof(cmdbuf), "%s %s", command, name);
+ return popen(cmdbuf, "r");
+}
/*
* Try to open specified file with following names:
@@ -267,15 +305,23 @@ static void zconf_endhelp(void)
*/
FILE *zconf_fopen(const char *name)
{
+ const struct type_handler *handler = get_type_handler(name);
char *env, fullname[PATH_MAX+1];
FILE *f;
- f = fopen(name, "r");
+ if (handler)
+ f = zconf_popen(handler->command, name);
+ else
+ f = fopen(name, "r");
+
if (!f && name != NULL && name[0] != '/') {
env = getenv(SRCTREE);
if (env) {
sprintf(fullname, "%s/%s", env, name);
- f = fopen(fullname, "r");
+ if (handler)
+ f = zconf_popen(handler->command, fullname);
+ else
+ f = fopen(fullname, "r");
}
}
return f;
--
Jeff Mahoney
SUSE Labs
This patch uses the type handlers to add /proc/config.gz as a configuration
source when 'make oldconfig' is used with a missing .config
Signed-off-by: Jeff Mahoney <[email protected]>
---
init/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -26,6 +26,7 @@ config DEFCONFIG_LIST
depends on !UML
option defconfig_list
default "/lib/modules/$UNAME_RELEASE/.config"
+ default "/proc/config.gz"
default "/etc/kernel-config"
default "/boot/config-$UNAME_RELEASE"
default "$ARCH_DEFCONFIG"
--
Jeff Mahoney
SUSE Labs
Hi,
On Fri, Feb 25, 2011 at 7:44 PM, Jeff Mahoney <[email protected]> wrote:
> ?This patch adds type handlers for compressed config files. Initial
> ?support provides callouts for gzip and bzip2, but there's no reason
> ?others could be added if demand is there.
>
> ?This is intended to allow /proc/config.gz be a configuration source
> ?for 'make oldconfig' when .config is absent.
>
this can be trivially scripted, any reason it _has_ to be done within kconfig ?
- Arnaud
> Signed-off-by: Jeff Mahoney <[email protected]>
> ---
>
> ?scripts/kconfig/zconf.l | ? 50 ++++++++++++++++++++++++++++++++++++++++++++++--
> ?1 file changed, 48 insertions(+), 2 deletions(-)
>
> --- a/scripts/kconfig/zconf.l
> +++ b/scripts/kconfig/zconf.l
> @@ -256,6 +256,44 @@ static void zconf_endhelp(void)
> ? ? ? ?BEGIN(INITIAL);
> ?}
>
> +static const struct type_handler {
> + ? ? ? const char *suffix;
> + ? ? ? const char *command;
> +} type_handlers[] = {
> + ? ? ? {
> + ? ? ? ? ? ? ? .suffix = ".gz",
> + ? ? ? ? ? ? ? .command = "zcat",
> + ? ? ? },
> + ? ? ? {
> + ? ? ? ? ? ? ? .suffix = ".bz2",
> + ? ? ? ? ? ? ? .command = "bzcat",
> + ? ? ? },
> + ? ? ? /* Whatever other algorithms you like */
> + ? ? ? {}
> +};
> +
> +static const struct type_handler *get_type_handler(const char *name)
> +{
> + ? ? ? char *p = rindex(name, '.');
> + ? ? ? if (p) {
> + ? ? ? ? ? ? ? const struct type_handler *ops = type_handlers;
> + ? ? ? ? ? ? ? for (ops = type_handlers; ops->suffix; ops++) {
> + ? ? ? ? ? ? ? ? ? ? ? if (!strcasecmp(ops->suffix, p))
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? if (!ops->suffix)
> + ? ? ? ? ? ? ? ? ? ? ? return NULL;
> + ? ? ? ? ? ? ? return ops;
> + ? ? ? }
> + ? ? ? return NULL;
> +}
> +
> +static FILE *zconf_popen(const char *command, const char *name)
> +{
> + ? ? ? char cmdbuf[PATH_MAX + strlen(command) + 2];
> + ? ? ? snprintf(cmdbuf, sizeof(cmdbuf), "%s %s", command, name);
> + ? ? ? return popen(cmdbuf, "r");
> +}
>
> ?/*
> ?* Try to open specified file with following names:
> @@ -267,15 +305,23 @@ static void zconf_endhelp(void)
> ?*/
> ?FILE *zconf_fopen(const char *name)
> ?{
> + ? ? ? const struct type_handler *handler = get_type_handler(name);
> ? ? ? ?char *env, fullname[PATH_MAX+1];
> ? ? ? ?FILE *f;
>
> - ? ? ? f = fopen(name, "r");
> + ? ? ? if (handler)
> + ? ? ? ? ? ? ? f = zconf_popen(handler->command, name);
> + ? ? ? else
> + ? ? ? ? ? ? ? f = fopen(name, "r");
> +
> ? ? ? ?if (!f && name != NULL && name[0] != '/') {
> ? ? ? ? ? ? ? ?env = getenv(SRCTREE);
> ? ? ? ? ? ? ? ?if (env) {
> ? ? ? ? ? ? ? ? ? ? ? ?sprintf(fullname, "%s/%s", env, name);
> - ? ? ? ? ? ? ? ? ? ? ? f = fopen(fullname, "r");
> + ? ? ? ? ? ? ? ? ? ? ? if (handler)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? f = zconf_popen(handler->command, fullname);
> + ? ? ? ? ? ? ? ? ? ? ? else
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? f = fopen(fullname, "r");
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
> ? ? ? ?return f;
>
> --
> Jeff Mahoney
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/25/2011 08:28 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Feb 25, 2011 at 7:44 PM, Jeff Mahoney <[email protected]> wrote:
>> This patch adds type handlers for compressed config files. Initial
>> support provides callouts for gzip and bzip2, but there's no reason
>> others could be added if demand is there.
>>
>> This is intended to allow /proc/config.gz be a configuration source
>> for 'make oldconfig' when .config is absent.
>>
> this can be trivially scripted, any reason it _has_ to be done within kconfig ?
This is what the original patch I posted did, and I was asked to teach
kconfig how to do it itself.
- -Jeff
>> Signed-off-by: Jeff Mahoney <[email protected]>
>> ---
>>
>> scripts/kconfig/zconf.l | 50 ++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 48 insertions(+), 2 deletions(-)
>>
>> --- a/scripts/kconfig/zconf.l
>> +++ b/scripts/kconfig/zconf.l
>> @@ -256,6 +256,44 @@ static void zconf_endhelp(void)
>> BEGIN(INITIAL);
>> }
>>
>> +static const struct type_handler {
>> + const char *suffix;
>> + const char *command;
>> +} type_handlers[] = {
>> + {
>> + .suffix = ".gz",
>> + .command = "zcat",
>> + },
>> + {
>> + .suffix = ".bz2",
>> + .command = "bzcat",
>> + },
>> + /* Whatever other algorithms you like */
>> + {}
>> +};
>> +
>> +static const struct type_handler *get_type_handler(const char *name)
>> +{
>> + char *p = rindex(name, '.');
>> + if (p) {
>> + const struct type_handler *ops = type_handlers;
>> + for (ops = type_handlers; ops->suffix; ops++) {
>> + if (!strcasecmp(ops->suffix, p))
>> + break;
>> + }
>> + if (!ops->suffix)
>> + return NULL;
>> + return ops;
>> + }
>> + return NULL;
>> +}
>> +
>> +static FILE *zconf_popen(const char *command, const char *name)
>> +{
>> + char cmdbuf[PATH_MAX + strlen(command) + 2];
>> + snprintf(cmdbuf, sizeof(cmdbuf), "%s %s", command, name);
>> + return popen(cmdbuf, "r");
>> +}
>>
>> /*
>> * Try to open specified file with following names:
>> @@ -267,15 +305,23 @@ static void zconf_endhelp(void)
>> */
>> FILE *zconf_fopen(const char *name)
>> {
>> + const struct type_handler *handler = get_type_handler(name);
>> char *env, fullname[PATH_MAX+1];
>> FILE *f;
>>
>> - f = fopen(name, "r");
>> + if (handler)
>> + f = zconf_popen(handler->command, name);
>> + else
>> + f = fopen(name, "r");
>> +
>> if (!f && name != NULL && name[0] != '/') {
>> env = getenv(SRCTREE);
>> if (env) {
>> sprintf(fullname, "%s/%s", env, name);
>> - f = fopen(fullname, "r");
>> + if (handler)
>> + f = zconf_popen(handler->command, fullname);
>> + else
>> + f = fopen(fullname, "r");
>> }
>> }
>> return f;
>>
>> --
>> Jeff Mahoney
>> SUSE Labs
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk1pOBcACgkQLPWxlyuTD7JlJACfVPh3NV+X5cz7l8BYgxkf1E2j
mGsAoIpMp0AMjIjl5mm3OaR2H3N65PpP
=Sd++
-----END PGP SIGNATURE-----
Hi,
On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
> We already have something remotely similar in kconfig.
> We use the following list:
> config DEFCONFIG_LIST
> ? ? ? ?string
> ? ? ? ?depends on !UML
> ? ? ? ?option defconfig_list
> ? ? ? ?default "/lib/modules/$UNAME_RELEASE/.config"
> ? ? ? ?default "/etc/kernel-config"
> ? ? ? ?default "/boot/config-$UNAME_RELEASE"
> ? ? ? ?default "$ARCH_DEFCONFIG"
> ? ? ? ?default "arch/$ARCH/defconfig"
>
I may argue that anything within the Linux tree which point
_by_default_ to something outside the tree itself is broken. Say I try
to build a Linux kernel on a system with has its own non-kconfig
`/etc/kernel-config', I guess this would make the configuration fail.
> It would be better to teach kconfig to read /proc/config.gz
> and then add it to the list above.
>
Why ? Thing should be kept simple. kconfig's job is not to know about
the trillion file format which exist in the world, even more if the
implementation is made by building a command[0], executing it in a
separate process and reading the output. This is the shell's job. What
may be useful in the contrary would be to eventually teach kconfig to
read from <stdin>.
- Arnaud
[0]: which is built depending on an extension, which is even more awful ...
> This list is used if you just type "make enuconfig" without
> any configuration.
>
> ? ? ? ?Sam
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Hi,
On Thu, Feb 24, 2011 at 9:35 PM, Jeff Mahoney <[email protected]> wrote:
> Cloneconfig takes the first configuration it finds which appears
> to belong to the running kernel, and configures the kernel sources
> to match this configuration as closely as possible.
>
> Signed-off-by: Andreas Gruenbacher <[email protected]>
> Signed-off-by: Jeff Mahoney <[email protected]>
> ---
> ?scripts/kconfig/Makefile | ? 17 +++++++++++++++++
> ?1 file changed, 17 insertions(+)
>
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -99,6 +99,23 @@ PHONY += allnoconfig allyesconfig allmod
>
> ?allnoconfig allyesconfig allmodconfig alldefconfig randconfig: $(obj)/conf
> ? ? ? ?$< --$@ $(Kconfig)
> +
> +UNAME_RELEASE := $(shell uname -r)
> +CLONECONFIG := $(firstword $(wildcard /proc/config.gz \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /lib/modules/$(UNAME_RELEASE)/.config \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /etc/kernel-config \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /boot/config-$(UNAME_RELEASE)))
> +cloneconfig: $(obj)/conf
> + ? ? ? $(Q)case "$(CLONECONFIG)" in ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? '') ? ? echo -e "The configuration of the running" ? ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? "kernel could not be determined\n"; ? ? \
You do not need the '\n', nor the '-e', echo(1) appends a newline by default.
> + ? ? ? ? ? ? ? false ;; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? *.gz) ? gzip -cd $(CLONECONFIG) > .config.running ;; ? ?\
> + ? ? ? *) ? ? ?cat $(CLONECONFIG) > .config.running ;; ? ? ? ? \
> + ? ? ? esac && ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? echo -e "Cloning configuration file $(CLONECONFIG)\n"
see above.
> + ? ? ? $(Q)$< -D .config.running arch/$(SRCARCH)/Kconfig
> +
>
> ?PHONY += listnewconfig oldnoconfig savedefconfig defconfig
>
> --
> Jeff Mahoney
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
On Sat, Feb 26, 2011 at 02:47:01PM -0500, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
> > We already have something remotely similar in kconfig.
> > We use the following list:
> > config DEFCONFIG_LIST
> > ? ? ? ?string
> > ? ? ? ?depends on !UML
> > ? ? ? ?option defconfig_list
> > ? ? ? ?default "/lib/modules/$UNAME_RELEASE/.config"
> > ? ? ? ?default "/etc/kernel-config"
> > ? ? ? ?default "/boot/config-$UNAME_RELEASE"
> > ? ? ? ?default "$ARCH_DEFCONFIG"
> > ? ? ? ?default "arch/$ARCH/defconfig"
> >
> I may argue that anything within the Linux tree which point
> _by_default_ to something outside the tree itself is broken.
The above allows the average user to just type "make menuconfig"
and then the configuration of the current kernel is presented to
the user. This is convinient in many cases.
We know the /proc/config.gz is an incresingly popular way to gain
access to the configuration of the running kernel. So extending
the already know and working way to obtaing the configuration
of the running kernel to suppport /proc/config.gz is logical.
The fact that the configuration is gzipped does not warrant
a new option to deal with this that almost duplicate the
existing functionality.
Sam
Hi,
On Sat, Feb 26, 2011 at 8:47 PM, Arnaud Lacombe <[email protected]> wrote:
> Hi,
>
> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
>> We already have something remotely similar in kconfig.
>> We use the following list:
>> config DEFCONFIG_LIST
>> ? ? ? ?string
>> ? ? ? ?depends on !UML
>> ? ? ? ?option defconfig_list
>> ? ? ? ?default "/lib/modules/$UNAME_RELEASE/.config"
>> ? ? ? ?default "/etc/kernel-config"
>> ? ? ? ?default "/boot/config-$UNAME_RELEASE"
>> ? ? ? ?default "$ARCH_DEFCONFIG"
>> ? ? ? ?default "arch/$ARCH/defconfig"
>>
> I may argue that anything within the Linux tree which point
> _by_default_ to something outside the tree itself is broken. Say I try
> to build a Linux kernel on a system with has its own non-kconfig
> `/etc/kernel-config', I guess this would make the configuration fail.
It is true that it may be annoying/unexpected, but the most common use
case is to build the kernel in the same machine which will run it.
In addition, it does not make the configuration fail, you just get the
machine's configuration. If you typed "menuconfig" instead of
"oldconfig" it means that you didn't have any configuration at all in
the first place, so if you are building a kernel for some other
machine you will have to configure through all the options manually
anyway.
>
>> It would be better to teach kconfig to read /proc/config.gz
>> and then add it to the list above.
>>
> Why ? Thing should be kept simple. kconfig's job is not to know about
> the trillion file format which exist in the world, even more if the
> implementation is made by building a command[0], executing it in a
> separate process and reading the output. This is the shell's job. What
> may be useful in the contrary would be to eventually teach kconfig to
> read from <stdin>.
/proc/config.gz is provided by the kernel and its format is defined by
kconfig itself which is, as well, part of the kernel (it is not one
random format from a pool of a trillion), so it will be nice if
kconfig learns how to read its own configuration from there.
kconfig only knows about config files (one format). The fact that it's
gzipped its irrelevant, any reasonable machine capable of building the
kernel has gzip installed.
>
> ?- Arnaud
>
> [0]: which is built depending on an extension, which is even more awful ...
>
>> This list is used if you just type "make enuconfig" without
>> any configuration.
>>
>> ? ? ? ?Sam
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
Hi,
On Sat, Feb 26, 2011 at 5:47 PM, Miguel Ojeda
<[email protected]> wrote:
> On Sat, Feb 26, 2011 at 8:47 PM, Arnaud Lacombe <[email protected]> wrote:
>> Why ? Thing should be kept simple. kconfig's job is not to know about
>> the trillion file format which exist in the world, even more if the
>> implementation is made by building a command[0], executing it in a
>> separate process and reading the output. This is the shell's job. What
>> may be useful in the contrary would be to eventually teach kconfig to
>> read from <stdin>.
>
> /proc/config.gz is provided by the kernel and its format is defined by
> kconfig itself which is, as well, part of the kernel (it is not one
> random format from a pool of a trillion), so it will be nice if
> kconfig learns how to read its own configuration from there.
>
your point being ? kconfig is not only used by the Linux kernel, and
you cannot expect the feature to only be used in the cozy Linux kernel
environment.
> kconfig only knows about config files (one format). The fact that it's
> gzipped its irrelevant, any reasonable machine capable of building the
> kernel has gzip installed.
>
again, the average user has no interaction with kconfig directly,
(s)he uses the top level Makefile target at best. The original patch
of Jeff is way better than any hack to read a gzip file from kconfig.
KISS and please don't reinvert the wheel.
- Arnaud
Hi,
On Sat, Feb 26, 2011 at 5:18 PM, Sam Ravnborg <[email protected]> wrote:
> On Sat, Feb 26, 2011 at 02:47:01PM -0500, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
>> > We already have something remotely similar in kconfig.
>> > We use the following list:
>> > config DEFCONFIG_LIST
>> > ? ? ? ?string
>> > ? ? ? ?depends on !UML
>> > ? ? ? ?option defconfig_list
>> > ? ? ? ?default "/lib/modules/$UNAME_RELEASE/.config"
>> > ? ? ? ?default "/etc/kernel-config"
>> > ? ? ? ?default "/boot/config-$UNAME_RELEASE"
>> > ? ? ? ?default "$ARCH_DEFCONFIG"
>> > ? ? ? ?default "arch/$ARCH/defconfig"
>> >
>> I may argue that anything within the Linux tree which point
>> _by_default_ to something outside the tree itself is broken.
> The above allows the average user to just type "make menuconfig"
> and then the configuration of the current kernel is presented to
> the user.
I'm sure there is a way to do this from the Kbuild and not from the Kconfig.
> This is convinient in many cases.
this is a subjective point of view. I do build a lot of kernel for
anything but the current machine I'm using.
> We know the /proc/config.gz is an incresingly popular way to gain
> access to the configuration of the running kernel. So extending
> the already know and working way to obtaing the configuration
> of the running kernel to suppport /proc/config.gz is logical.
Then again, this should be doable from Kbuild.
> The fact that the configuration is gzipped does not warrant
> a new option to deal with this that almost duplicate the
> existing functionality.
>
agree.
- Arnaud
On Sat, Feb 26, 2011 at 11:57 PM, Arnaud Lacombe <[email protected]> wrote:
> Hi,
>
> On Sat, Feb 26, 2011 at 5:47 PM, Miguel Ojeda
> <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 8:47 PM, Arnaud Lacombe <[email protected]> wrote:
>>> Why ? Thing should be kept simple. kconfig's job is not to know about
>>> the trillion file format which exist in the world, even more if the
>>> implementation is made by building a command[0], executing it in a
>>> separate process and reading the output. This is the shell's job. What
>>> may be useful in the contrary would be to eventually teach kconfig to
>>> read from <stdin>.
>>
>> /proc/config.gz is provided by the kernel and its format is defined by
>> kconfig itself which is, as well, part of the kernel (it is not one
>> random format from a pool of a trillion), so it will be nice if
>> kconfig learns how to read its own configuration from there.
>>
> your point being ? kconfig is not only used by the Linux kernel, and
> you cannot expect the feature to only be used in the cozy Linux kernel
> environment.
My point was that supporting reading from a .gz file is not anywhere
near "knowing about the trillion file format which exist in the world"
(and I was not talking about a "hack", see below).
>
>> kconfig only knows about config files (one format). The fact that it's
>> gzipped its irrelevant, any reasonable machine capable of building the
>> kernel has gzip installed.
>>
> again, the average user has no interaction with kconfig directly,
> (s)he uses the top level Makefile target at best. The original patch
> of Jeff is way better than any hack to read a gzip file from kconfig.
> KISS and please don't reinvert the wheel.
I agree with that. I understood that you were against adding support
for reading /proc/config.gz whether patching the Makefile or teaching
kconfig how to do that.
Miguel
>
> ?- Arnaud
>
Hi,
On Sat, Feb 26, 2011 at 6:16 PM, Miguel Ojeda
<[email protected]> wrote:
> On Sat, Feb 26, 2011 at 11:57 PM, Arnaud Lacombe <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 5:47 PM, Miguel Ojeda
>> <[email protected]> wrote:
>>> /proc/config.gz is provided by the kernel and its format is defined by
>>> kconfig itself which is, as well, part of the kernel (it is not one
>>> random format from a pool of a trillion), so it will be nice if
>>> kconfig learns how to read its own configuration from there.
>>>
>> your point being ? kconfig is not only used by the Linux kernel, and
>> you cannot expect the feature to only be used in the cozy Linux kernel
>> environment.
>
> My point was that supporting reading from a .gz file is not anywhere
> near "knowing about the trillion file format which exist in the world"
>
Well, Jeff's patch is already about gzip and bzip2. Soon it will be
compress, xz, zip, rar, then rzip, lzma, 7z ...
- Arnaud
Hi,
On Sat, Feb 26, 2011 at 6:03 PM, Arnaud Lacombe <[email protected]> wrote:
>> The fact that the configuration is gzipped does not warrant
>> a new option to deal with this that almost duplicate the
>> existing functionality.
>>
> agree.
>
Let me precise, as there may be confusion. I agree about the new
target issue, but definitively think this kconfig "option" (more a
hack, which required a special option within kconfig) should be
handled by Kbuild, not Kconfig, ie. I'd discard "option
defconfig_list". File decompression (and eventually which config to
pick) should be done prior to the invocation of Kconfig.
- Arnaud
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/26/2011 05:57 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Sat, Feb 26, 2011 at 5:47 PM, Miguel Ojeda
> <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 8:47 PM, Arnaud Lacombe <[email protected]> wrote:
>>> Why ? Thing should be kept simple. kconfig's job is not to know about
>>> the trillion file format which exist in the world, even more if the
>>> implementation is made by building a command[0], executing it in a
>>> separate process and reading the output. This is the shell's job. What
>>> may be useful in the contrary would be to eventually teach kconfig to
>>> read from <stdin>.
>>
>> /proc/config.gz is provided by the kernel and its format is defined by
>> kconfig itself which is, as well, part of the kernel (it is not one
>> random format from a pool of a trillion), so it will be nice if
>> kconfig learns how to read its own configuration from there.
>>
> your point being ? kconfig is not only used by the Linux kernel, and
> you cannot expect the feature to only be used in the cozy Linux kernel
> environment.
But this argument isn't really relevant. As with all of the other files
listed in the defconfig_list, if it's missing (or can't be read), it
will move on to the next one. Decompressing it first just makes things
/more/ confusing since the initial message of 'defaults read from...'
will read the name of the decompressed temporary file, not the source.
It makes more sense to see it as "reading defaults from /proc/config.gz
since that's obvious to anyone with kernel experience.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk1pjfEACgkQLPWxlyuTD7Ki0wCfU8KrumyxlD+qTFajlhc1eHOn
rMoAn0PqPyBYhBWlFTBT8YaL8/MWjw1J
=PVwv
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/26/2011 06:26 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Sat, Feb 26, 2011 at 6:16 PM, Miguel Ojeda
> <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 11:57 PM, Arnaud Lacombe <[email protected]> wrote:
>>> On Sat, Feb 26, 2011 at 5:47 PM, Miguel Ojeda
>>> <[email protected]> wrote:
>>>> /proc/config.gz is provided by the kernel and its format is defined by
>>>> kconfig itself which is, as well, part of the kernel (it is not one
>>>> random format from a pool of a trillion), so it will be nice if
>>>> kconfig learns how to read its own configuration from there.
>>>>
>>> your point being ? kconfig is not only used by the Linux kernel, and
>>> you cannot expect the feature to only be used in the cozy Linux kernel
>>> environment.
>>
>> My point was that supporting reading from a .gz file is not anywhere
>> near "knowing about the trillion file format which exist in the world"
>>
> Well, Jeff's patch is already about gzip and bzip2. Soon it will be
> compress, xz, zip, rar, then rzip, lzma, 7z ...
I added bzip2 as an exercise. But realistically, what would be wrong
with distributors deciding to ship /boot/config-$UNAME_RELEASE.bz2 and
saving a bit of valuable /boot disk space?
Even if people /do/ submit patches do do all of those formats, your
argument is based on the premise that having that ability is necessarily
bad. I don't think we need them, but I don't think it's a good argument
against this patch either.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk1pjxIACgkQLPWxlyuTD7Jm3wCfSG6z1aBOT6PDLVmQeycW5mmM
Z/IAoJJXW7P5C+cWg8lFSTmm+HtBjR0E
=b5Hc
-----END PGP SIGNATURE-----
Hi,
On Sat, Feb 26, 2011 at 6:38 PM, Jeff Mahoney <[email protected]> wrote:
> I added bzip2 as an exercise. But realistically, what would be wrong
> with distributors deciding to ship /boot/config-$UNAME_RELEASE.bz2 and
> saving a bit of valuable /boot disk space?
>
I don't really care, that's outside of kconfig prerogative.
> Even if people /do/ submit patches do do all of those formats, your
> argument is based on the premise that having that ability is necessarily
> bad. I don't think we need them, but I don't think it's a good argument
> against this patch either.
>
you welcome a lot of potential bloat and wheel re-invention. Both are bad.
- Arnaud
Hi,
On Sat, Feb 26, 2011 at 6:34 PM, Jeff Mahoney <[email protected]> wrote:
> But this argument isn't really relevant. As with all of the other files
> listed in the defconfig_list, if it's missing (or can't be read), it
> will move on to the next one. Decompressing it first just makes things
> /more/ confusing since the initial message of 'defaults read from...'
> will read the name of the decompressed temporary file, not the source.
> It makes more sense to see it as "reading defaults from /proc/config.gz
> since that's obvious to anyone with kernel experience.
>
no, this would only be the behavior of the way you did it.
- Arnaud
On Sat, Feb 26, 2011 at 23:18, Sam Ravnborg <[email protected]> wrote:
> On Sat, Feb 26, 2011 at 02:47:01PM -0500, Arnaud Lacombe wrote:
>> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
>> > We already have something remotely similar in kconfig.
>> > We use the following list:
>> > config DEFCONFIG_LIST
>> > string
>> > depends on !UML
>> > option defconfig_list
>> > default "/lib/modules/$UNAME_RELEASE/.config"
>> > default "/etc/kernel-config"
>> > default "/boot/config-$UNAME_RELEASE"
>> > default "$ARCH_DEFCONFIG"
>> > default "arch/$ARCH/defconfig"
>> >
>> I may argue that anything within the Linux tree which point
>> _by_default_ to something outside the tree itself is broken.
> The above allows the average user to just type "make menuconfig"
> and then the configuration of the current kernel is presented to
> the user. This is convinient in many cases.
> We know the /proc/config.gz is an incresingly popular way to gain
> access to the configuration of the running kernel. So extending
> the already know and working way to obtaing the configuration
> of the running kernel to suppport /proc/config.gz is logical.
Does this detect cross-compiling? The 'depends on !UML' triggered me...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi,
On Sun, Feb 27, 2011 at 4:03 AM, Geert Uytterhoeven
<[email protected]> wrote:
> On Sat, Feb 26, 2011 at 23:18, Sam Ravnborg <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 02:47:01PM -0500, Arnaud Lacombe wrote:
>>> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
>>> > We already have something remotely similar in kconfig.
>>> > We use the following list:
>>> > config DEFCONFIG_LIST
>>> > ? ? ? ?string
>>> > ? ? ? ?depends on !UML
>>> > ? ? ? ?option defconfig_list
>>> > ? ? ? ?default "/lib/modules/$UNAME_RELEASE/.config"
>>> > ? ? ? ?default "/etc/kernel-config"
>>> > ? ? ? ?default "/boot/config-$UNAME_RELEASE"
>>> > ? ? ? ?default "$ARCH_DEFCONFIG"
>>> > ? ? ? ?default "arch/$ARCH/defconfig"
>>> >
>>> I may argue that anything within the Linux tree which point
>>> _by_default_ to something outside the tree itself is broken.
>> The above allows the average user to just type "make menuconfig"
>> and then the configuration of the current kernel is presented to
>> the user. This is convinient in many cases.
>> We know the /proc/config.gz is an incresingly popular way to gain
>> access to the configuration of the running kernel. So extending
>> the already know and working way to obtaing the configuration
>> of the running kernel to suppport /proc/config.gz is logical.
>
> Does this detect cross-compiling?
>
No.
% gmake ARCH=mips menuconfig
#
# using defaults found in /boot/config-2.6.35.11-83.fc14.x86_64
#
[...]
% gmake CROSS_COMPILE=bla ARCH=mips menuconfig
#
# using defaults found in /boot/config-2.6.35.11-83.fc14.x86_64
#
[...]
Which is plainly just wrong.
- Arnaud
> Gr{oetje,eeting}s,
>
> ? ? ? ? ? ? ? ? ? ? ? ? Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/27/2011 04:03 AM, Geert Uytterhoeven wrote:
> On Sat, Feb 26, 2011 at 23:18, Sam Ravnborg <[email protected]> wrote:
>> On Sat, Feb 26, 2011 at 02:47:01PM -0500, Arnaud Lacombe wrote:
>>> On Fri, Feb 25, 2011 at 1:07 AM, Sam Ravnborg <[email protected]> wrote:
>>>> We already have something remotely similar in kconfig.
>>>> We use the following list:
>>>> config DEFCONFIG_LIST
>>>> string
>>>> depends on !UML
>>>> option defconfig_list
>>>> default "/lib/modules/$UNAME_RELEASE/.config"
>>>> default "/etc/kernel-config"
>>>> default "/boot/config-$UNAME_RELEASE"
>>>> default "$ARCH_DEFCONFIG"
>>>> default "arch/$ARCH/defconfig"
>>>>
>>> I may argue that anything within the Linux tree which point
>>> _by_default_ to something outside the tree itself is broken.
>> The above allows the average user to just type "make menuconfig"
>> and then the configuration of the current kernel is presented to
>> the user. This is convinient in many cases.
>> We know the /proc/config.gz is an incresingly popular way to gain
>> access to the configuration of the running kernel. So extending
>> the already know and working way to obtaing the configuration
>> of the running kernel to suppport /proc/config.gz is logical.
>
> Does this detect cross-compiling? The 'depends on !UML' triggered me...
No, and it never has. The DEFCONFIG_LIST feature has been mostly
unaltered since it was added in Jun 2006. Prior to that it was hardcoded
into scripts/kconfig/confdata.c since before 2002.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk1qj7kACgkQLPWxlyuTD7J/ZwCfQzFM6Qo+1Va5RTYKj4bXEydm
28EAoINVyrH+F4hYhCWSkXYCq3Y0euY/
=T1qc
-----END PGP SIGNATURE-----
On Sat, Feb 26, 2011 at 06:28:43PM -0500, Arnaud Lacombe wrote:
> Hi,
>
> On Sat, Feb 26, 2011 at 6:03 PM, Arnaud Lacombe <[email protected]> wrote:
> >> The fact that the configuration is gzipped does not warrant
> >> a new option to deal with this that almost duplicate the
> >> existing functionality.
> >>
> > agree.
> >
> Let me precise, as there may be confusion. I agree about the new
> target issue, but definitively think this kconfig "option" (more a
> hack, which required a special option within kconfig) should be
> handled by Kbuild, not Kconfig, ie. I'd discard "option
> defconfig_list". File decompression (and eventually which config to
> pick) should be done prior to the invocation of Kconfig.
If you can come up with something simpler and better than
what we have today then fine.
Simplifying kconfgi would be good.
But at least barebox uses defconfig_list - an maybe others.
We need to consider non-kernel users too.
Sam