Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
> This all began (AFAIK) because some of us want to continue to be
> able to specify ARCH={i386,x86_64} on the (make) command line --
> not by using a .config file. Taking away ARCH= on the command line
> is a regression (in some minds, at least), so
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
> 1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
> 2) A pure code refactoring patch is reverted for no obvious
Hi,
On Fri, 16 Nov 2007, Sam Ravnborg wrote:
1) make all*config, randconfig, defconfig is broken on 64-bit boxes
With your approach you made it impossible to set 64BIT from all*.config,
which is the proper way to set the defaults.
2) A pure code refactoring patch is reverted for no obvious
Hi,
On Thu, 15 Nov 2007, Randy Dunlap wrote:
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam
Hi Roman.
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64},
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
> Hi,
>
> On Thu, 15 Nov 2007, Sam Ravnborg wrote:
>
> > You suggest just to check ARCH value and not apply your patch. This was
> > not my initial understanding as was hopefully obvious from my reply.
>
> This patch only adds some
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> You suggest just to check ARCH value and not apply your patch. This was
> not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
> If user did NOT specify ARCH we should use the kernel
On Thu, Nov 15, 2007 at 10:24:05PM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 15 Nov 2007, Sam Ravnborg wrote:
>
> > > Can we please can get some consistency in this?
> > > We have a .config file for a reason, what's wrong with using it?
> >
> > We need to set a selected few values in a few
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> > Can we please can get some consistency in this?
> > We have a .config file for a reason, what's wrong with using it?
>
> We need to set a selected few values in a few cases where we do
> not have a .config file.
> allmodconfig for x86 for
Hi Roman.
> > > > 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.
>
> Can we please can
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
Hi,
On Thu, 15 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
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?
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
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?
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
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
Hi,
On Thu, 15 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.
Can we
Hi Roman.
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.
Can we please can get some
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
Can we please can get some consistency in this?
We have a .config file for a reason, what's wrong with using it?
We need to set a selected few values in a few cases where we do
not have a .config file.
allmodconfig for x86 for instance. We
On Thu, Nov 15, 2007 at 10:24:05PM +0100, Roman Zippel wrote:
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
Can we please can get some consistency in this?
We have a .config file for a reason, what's wrong with using it?
We need to set a selected few values in a few cases where we
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
You suggest just to check ARCH value and not apply your patch. This was
not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
If user did NOT specify ARCH we should use the kernel
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
You suggest just to check ARCH value and not apply your patch. This was
not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra
Hi Roman.
If user did NOT specify ARCH we should use the kernel configuration - which
your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64},
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 =
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 ==
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) {
+
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;
+
On 11/11/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > So it's not strictly an
> > output directory, more a build directory.
> The opposite
> All output is placed there - including the configuration generated by
> the *config frontends.
I meant, it's not strictly an output directory as if I
On Sun, Nov 11, 2007 at 03:59:54PM +0100, Guillaume Chazarain wrote:
> > I'm wondering why you don't use two different O= output directories
> > instead?
> >
> > Depending on the CONFIG_ option in question this might even greatly
> > reduce your compile times.
>
> /me is filled with wonder at the
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Another important point is that users that know about and see CONFIG_*
> variables are kernel hackers, not the normal kconfig users.
But kconfig is mainly for kernel hackers, otherwise it would be
called CML2 ;-)
> > Also, when working on a
On Sun, Nov 11, 2007 at 01:43:28PM +0100, Guillaume Chazarain wrote:
> Hi Adrian,
Hi Guillaume,
> On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > What exactly are the use cases where someone would need this?
>
> Glad you asked. Today, when I want to recompile a kernel while
> changing a
Hi Adrian,
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_ option, I manually edit the .config,
remove the appropriate line and then run make
Hi Adrian,
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote:
What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_ option, I manually edit the .config,
remove the appropriate line and then run make
On Sun, Nov 11, 2007 at 01:43:28PM +0100, Guillaume Chazarain wrote:
Hi Adrian,
Hi Guillaume,
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote:
What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Another important point is that users that know about and see CONFIG_*
variables are kernel hackers, not the normal kconfig users.
But kconfig is mainly for kernel hackers, otherwise it would be
called CML2 ;-)
Also, when working on a
On Sun, Nov 11, 2007 at 03:59:54PM +0100, Guillaume Chazarain wrote:
I'm wondering why you don't use two different O= output directories
instead?
Depending on the CONFIG_ option in question this might even greatly
reduce your compile times.
/me is filled with wonder at the discovery
On 11/11/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
So it's not strictly an
output directory, more a build directory.
The opposite
All output is placed there - including the configuration generated by
the *config frontends.
I meant, it's not strictly an output directory as if I do
make
On Sat, Nov 10, 2007 at 09:55:06PM +0100, Guillaume Chazarain wrote:
> Hi,
>
> On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > The variable K64BIT can now be used to select the
> > value of CONFIG_64BIT.
>
> Why not calling the environment variable CONFIG_64BIT,
> in preparation of the
On Sat, Nov 10, 2007 at 02:16:19PM -0800, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
>
> > The variable K64BIT can now be used to select the
> > value of CONFIG_64BIT.
> >
> > This is for example useful for powerpc to generate
> > allmodconfig for both bit sizes
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
>
> This is for example useful for powerpc to generate
> allmodconfig for both bit sizes - like this:
> make ARCH=powerpc K64BIT=y
> make ARCH=powerpc K64BIT=n
>
>
Hi,
On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?
--
Guillaume
Hi,
On 11/10/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?
--
Guillaume
-
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
This is for example useful for powerpc to generate
allmodconfig for both bit sizes - like this:
make ARCH=powerpc K64BIT=y
make ARCH=powerpc K64BIT=n
To use
On Sat, Nov 10, 2007 at 02:16:19PM -0800, Randy Dunlap wrote:
On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
This is for example useful for powerpc to generate
allmodconfig for both bit sizes - like
On Sat, Nov 10, 2007 at 09:55:06PM +0100, Guillaume Chazarain wrote:
Hi,
On 11/10/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all
44 matches
Mail list logo
