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: <20071115192555.GD23914@uranus.ravnborg.org>
Date:	Thu, 15 Nov 2007 20:25:55 +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

On Thu, Nov 15, 2007 at 04:43:03PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 14 Nov 2007, Sam Ravnborg wrote:
> 
> > The value can be supplied on the command-line so we need to validate input.
> 
> Is there a need for this?
Yes. We would like to set 64BIT or not in other than x86 cases.
And way forward was not to override ARCH as in the x86 case.


> BTW ARCH was already available as a value in the Kconfig files, so setting 
> the 64BIT option was already possible without any changes the kconfig 
> system, e.g.:
> 
> config 64BIT
> 	bool "64 Bit kernel" if ARCH!="i386" && ARCH!="x86_64"
> 	default ARCH="x86_64"

I thought this was not possible but it must have been the limitation
of choice symbols I have hit when I played with it.


> The patch below adds some features to it:
> - it allows to import any environment variable by specifying "option env=..."
> - it generates a dependency on it, so the kernel config is updated if it 
> changes.
> 
> Please revert the K64BIT changes and use this instead.

I will finish up your patch and target it for next merge window.
Thanks.

> 
> > 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?
> 
> These are two different uses, when reading a .config only the basic syntax 
> is checked, but not the value itself.
This is wrong considering the amount of people that hand edit the .config file.


> > 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?
> 
> It allows to hold multiple configs, a user of it is conf_split_config() 
> which loads another config and compares to the current config and updates 
> the files under include/config as needed.
> It could also be used by front ends to display what actually changed 
> compared to e.g. the saved config.

Took a deeper look.
So we can have 4 different set of vlaues where the value indexed by S_DEF_USER
is the one that is actually used and the other three can be used to hold values.

I will try to document this in expr.h
Patch will be sent to you for review.

> > 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?
> 
> The basic idea is to add a name to the choice, so multiple choices can be 
> grouped together. This requires some changes to the dependency check to 
> make sure one choice option doesn't depend on another (which is currently 
> enforced by the syntax).
Do you have any suggestions how to properly fix this?

	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/