linux-kernel - Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071114220840.GB10920@uranus.ravnborg.org>
Date:	Wed, 14 Nov 2007 23:08:40 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets

Hi Roman

On Wed, Nov 14, 2007 at 09:57:32PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Sat, 10 Nov 2007, Sam Ravnborg wrote:
> 
> > +	if (p) {
> > +		char warning[100];
> > +		sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> > +		conf_filename = warning;
> > +		def_flags = SYMBOL_DEF << def;
> > +		if (def == S_DEF_USER) {
> > +			sym = sym_find(symname);
> > +			if (!sym)
> > +				return 1;
> > +		} else {
> > +			sym = sym_lookup(symname, 0);
> > +			if (sym->type == S_UNKNOWN)
> > +				sym->type = S_OTHER;
> > +		}
> > +		conf_set_sym_val(sym, def, def_flags, p);
> > +	}
> > +	return 0;
> 
> This is more complex than necessary, this should be enough:
> 
> 	sym = sym_find(symname);
> 	if (sym)
> 		sym_set_string_value(sym, p);
> 
> This is not a direct user interface, so the potential stricter error 
> checking is not really needed.
The value can be supplied on the command-line so we need to validate input.
The code is a copy of what happen when reading a all.config file and
the functionality should be equal.
Can we make that part simpler too?

By the way - I have never understood the purpose of the flags (S_DEF_USER etc.)
Can we have a few comments added to their definition?

> In general I think it's problematic that this is only checked, when the 
> config system is called, i.e. with a configured kernel adding ARCH would 
> have no effect, what makes this more confusing is that one can later omit 
> the ARCH variable, since it's saved in the .config.

The future plan is to set the architecture as part of the configuration step
and not by ARCH=. The ARCH= notation will continue to be supported
but will merely be a hint about the desired architecture.

The only place where it will play a real effect is when generating
allnoconfig, allyesconfig, allmodconfig, randconfig.

Some consistency check will likely be added - but a pure 'make' will
build the kernel with the configured ARCH and the configured CROSS_COMPILE
setting.

One of the blockers are that kconfig does not support more than one prompt
for a choice symbol. Is this something you can fix - or sketch how to fix it?

	Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/