linux-kernel - Re: [PATCH 7/7] kconfig: search for a config to base the local(mod|yes)config on

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]

Date:	Mon, 4 May 2009 10:46:34 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Theodore Tso <tytso@....edu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	zippel@...ux-m68k.org, linux-kbuild@...r.kernel.org,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH 7/7] kconfig: search for a config to base the
 local(mod|yes)config on


On Mon, 4 May 2009, Peter Zijlstra wrote:

> On Mon, 2009-05-04 at 14:15 +0200, Andi Kleen wrote:
> > Steven Rostedt <rostedt@...dmis.org> writes:
> > 
> > > Here's the list and order of search:
> > >
> > >   /proc/config.gz
> > >   /boot/vmlinuz-`uname -r`
> > >   vmlinux  # local to the directory
> > >   /lib/modules/`uname -r`/kernel/kernel/configs.ko
> > >   kernel/configs.ko
> > >   kernel/configs.o
> > >   .config
> > 
> > 
> > That seems like the wrong order. ./.config should always be first for
> > compatibility. 
> > 
> > That order would completely wreck all my build scripts, and I suspect
> > others too.
> 
> Quite, except that I hardly ever have a ./.config since I make extensive
> use of O=foo

I'm fine with using .config as first choice (that is what the script 
originally did) but I wanted to make it as easy for non developers as 
possible. Taking from /proc or /boot was most likely the best to give a 
minimal boot environment.

But I can see why .config is probably the best choice for having the most 
power with the tool. It is how you can always force it to do something you 
want, and is the most logical place to expect the script to read from.

I'll update it.

Thanks,

-- Steve

--
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/