[argh. sent to arm list by mistake first time.]
'make allnoconfig' generates a broken .config on arm because
none of the boolean CPU types get selected.
ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
default if ARCH_RPC, but that doesn't help, since allnoconfig
sets all booleans that are exposed to the user to false, so
CPU_SA110 remains false.
Hiding the CPU_SA110 rule from the user (and thus from allnoconfig)
either by removing the prompt, or by modifying the CPU_SA110 rule
by adding && !ARCH_RPC to the end of the prompt,
does in fact allow 'make arch=arm allnoconfig' to generate a good .config file.
That's not a fix, as it breaks interactive configuration, but it does suggest a fix:
add a 'allnoconfig' boolean one can sense in Kconfig files.
Then Kconfig authors could hide precious default boolean
options from the wrath of allnoconfig by adding a 'if !allnoconfig' on the
menu statement.
I tried it (see patch below), but couldn't get it to work in first
few tries. Can someone who understands kconfig have a look?
Thanks!
- Dan
--- linux-2.6.5/scripts/kconfig/conf.c.old Mon Sep 13 00:13:34 2004
+++ linux-2.6.5/scripts/kconfig/conf.c Mon Sep 13 00:23:51 2004
@@ -28,6 +28,8 @@
} input_mode = ask_all;
char *defconfig_file;
+int allnoconfig = 0; /* kludge. Set in main(), read in sym_init(). */
+
static int indent = 1;
static int valid_stdin = 1;
static int conf_cnt;
@@ -511,6 +513,7 @@
break;
case 'n':
input_mode = set_no;
+ allnoconfig = 1;
break;
case 'm':
input_mode = set_mod;
--- linux-2.6.5/scripts/kconfig/zconf.tab.c.old Mon Sep 13 00:20:33 2004
+++ linux-2.6.5/scripts/kconfig/zconf.tab.c Mon Sep 13 00:29:02 2004
@@ -1925,6 +1925,13 @@
modules_sym = sym_lookup("MODULES", 0);
rootmenu.prompt = menu_add_prop(P_MENU, "Linux Kernel Configuration", NULL, NULL);
+ /* Let config files know if -n is in force so they can hide important defaults */
+ {
+ struct symbol *sym = sym_lookup("allnoconfig", 0);
+ extern int allnoconfig;
+ sym_set_tristate_value(sym, allnoconfig ? yes : no);
+ }
+
//zconfdebug = 1;
zconfparse();
if (zconfnerrs)
--- linux-2.6.5/arch/arm/mm/Kconfig.old Sun Sep 12 23:21:12 2004
+++ linux-2.6.5/arch/arm/mm/Kconfig Mon Sep 13 00:25:33 2004
@@ -185,8 +185,11 @@
# SA110
config CPU_SA110
- bool "Support StrongARM(R) SA-110 processor" if !ARCH_EBSA110 && !FOOTBRIDGE && !ARCH_TBOX && !ARCH_SHARK && !ARCH_NEXUSPCI && ARCH_RPC
- default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_TBOX || ARCH_SHARK || ARCH_NEXUSPCI
+ bool "Support StrongARM(R) SA-110 processor" if !ARCH_EBSA110 && !FOOTBRIDGE && !ARCH_TBOX && !ARCH_SHARK && !ARCH_NEXUSPCI && !allnoconfig
+ # Note: the RiscPC from Acorn shipped with several microprocessors over the years.
+ # It is arguably wrong to pick one of them as the default, but we have to if we
+ # want 'make allnoconfig' to work.
+ default y if ARCH_EBSA110 || FOOTBRIDGE || ARCH_TBOX || ARCH_SHARK || ARCH_NEXUSPCI || ARCH_RPC
select CPU_32v3 if ARCH_RPC
select CPU_32v4 if !ARCH_RPC
select CPU_ABRT_EV4
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
On Mon, Sep 13, 2004 at 12:53:33AM -0700, Dan Kegel wrote:
> 'make allnoconfig' generates a broken .config on arm because
> none of the boolean CPU types get selected.
> ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
> default if ARCH_RPC, but that doesn't help, since allnoconfig
> sets all booleans that are exposed to the user to false, so
> CPU_SA110 remains false.
allnoconfig is broken. It doesn't generate a legal configuration on
this platform.
There are cases where you have the choice of selecting several options
and you may select one or more. Zero options selected is not valid.
Unfortunately, Kconfig does not provide a way to express this.
> I tried it (see patch below), but couldn't get it to work in first
> few tries. Can someone who understands kconfig have a look?
I don't think hacking around allnoconfig works - it means that we
have to decide on a default for every configuration. ARCH_RPC is
only one such small case. There's loads more.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> On Mon, Sep 13, 2004 at 12:53:33AM -0700, Dan Kegel wrote:
>
>>'make allnoconfig' generates a broken .config on arm because
>>none of the boolean CPU types get selected.
>>ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
>>default if ARCH_RPC, but that doesn't help, since allnoconfig
>>sets all booleans that are exposed to the user to false, so
>>CPU_SA110 remains false.
>
>
> allnoconfig is broken. It doesn't generate a legal configuration on
> this platform.
I think that's what I said. I guess you're saying it more forcefully;
you seem to be implying "the basic idea of allnoconfig is broken."
> There are cases where you have the choice of selecting several options
> and you may select one or more. Zero options selected is not valid.
> Unfortunately, Kconfig does not provide a way to express this.
I think that's also what I said.
>>I tried it (see patch below), but couldn't get it to work in first
>>few tries. Can someone who understands kconfig have a look?
>
>
> I don't think hacking around allnoconfig works - it means that we
> have to decide on a default for every configuration. ARCH_RPC is
> only one such small case. There's loads more.
I guess it depends on your goals. My goal is to use allnoconfig
as a toolchain regression test. For each arch, I want an easy way
to build some kernel (any kernel!) for that arch. ARCH_RPC
is the default on arm (yes, I know you think the whole
concept of defaults on arm is broken), so it's the only one that
needs fixing.
Any feedback from people who don't think allnoconfig is a useless idea?
Thanks,
Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
On Mon, Sep 13, 2004 at 08:22:24AM -0700, Dan Kegel wrote:
> Russell King wrote:
> > On Mon, Sep 13, 2004 at 12:53:33AM -0700, Dan Kegel wrote:
> >
> >>'make allnoconfig' generates a broken .config on arm because
> >>none of the boolean CPU types get selected.
> >>ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
> >>default if ARCH_RPC, but that doesn't help, since allnoconfig
> >>sets all booleans that are exposed to the user to false, so
> >>CPU_SA110 remains false.
> >
> >
> > allnoconfig is broken. It doesn't generate a legal configuration on
> > this platform.
>
> I think that's what I said. I guess you're saying it more forcefully;
> you seem to be implying "the basic idea of allnoconfig is broken."
Indeed - we can go around fixing the configuration to work on each
individual machine type, but... have you checked how many platforms
there are, and are you volunteering to test the kernel configuration
for each one?
I can tell you that, eg, IDE makes sense on SA1100 platform X but
not Y or Z. Do we _really_ want to express this level of complexity
in the kernel configuration?
On ARM, there are over 500 platform types in the database (ok, not
all of them are merged or even exist anymore, but that's still a
substantial number.) It is obviously completely impossible to rig
up the Kconfig subsystem such that every platform has a valid
configuration.
> I guess it depends on your goals. My goal is to use allnoconfig
> as a toolchain regression test. For each arch, I want an easy way
> to build some kernel (any kernel!) for that arch. ARCH_RPC
> is the default on arm (yes, I know you think the whole
> concept of defaults on arm is broken), so it's the only one that
> needs fixing.
Well, you're going to run into the same problem with Versatile and
the Integrator class of platforms as well.
Basically, there's a fair amount of conditions under which Kconfig
fails to perform reasonably, and these (little used) targets are
an example of that.
If you want something that's guaranteed to work, use one of the
per-platform default configurations. Nothing else carries any
guarantee what so ever on ARM.
(Also, I have no interest in all*config myself so even if someone
does fix it, chances are it'll get broken again. I believe that
the concept of all*config is a fundamentally broken concept for an
architecture with numerous platform configurations.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Mon, Sep 13, 2004 at 07:51:19PM +0100, Russell King wrote:
> On Mon, Sep 13, 2004 at 08:22:24AM -0700, Dan Kegel wrote:
> > Russell King wrote:
> > > On Mon, Sep 13, 2004 at 12:53:33AM -0700, Dan Kegel wrote:
> > >
> > >>'make allnoconfig' generates a broken .config on arm because
> > >>none of the boolean CPU types get selected.
> > >>ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
> > >>default if ARCH_RPC, but that doesn't help, since allnoconfig
> > >>sets all booleans that are exposed to the user to false, so
> > >>CPU_SA110 remains false.
> > >
> > >
> > > allnoconfig is broken. It doesn't generate a legal configuration on
> > > this platform.
> >
> > I think that's what I said. I guess you're saying it more forcefully;
> > you seem to be implying "the basic idea of allnoconfig is broken."
>
> Indeed - we can go around fixing the configuration to work on each
> individual machine type, but... have you checked how many platforms
> there are, and are you volunteering to test the kernel configuration
> for each one?
>
> I can tell you that, eg, IDE makes sense on SA1100 platform X but
> not Y or Z. Do we _really_ want to express this level of complexity
> in the kernel configuration?
>
> On ARM, there are over 500 platform types in the database (ok, not
> all of them are merged or even exist anymore, but that's still a
> substantial number.) It is obviously completely impossible to rig
> up the Kconfig subsystem such that every platform has a valid
> configuration.
>
> > I guess it depends on your goals. My goal is to use allnoconfig
> > as a toolchain regression test. For each arch, I want an easy way
> > to build some kernel (any kernel!) for that arch. ARCH_RPC
> > is the default on arm (yes, I know you think the whole
> > concept of defaults on arm is broken), so it's the only one that
> > needs fixing.
>
> Well, you're going to run into the same problem with Versatile and
> the Integrator class of platforms as well.
>
> Basically, there's a fair amount of conditions under which Kconfig
> fails to perform reasonably, and these (little used) targets are
> an example of that.
>
> If you want something that's guaranteed to work, use one of the
> per-platform default configurations. Nothing else carries any
> guarantee what so ever on ARM.
>
> (Also, I have no interest in all*config myself so even if someone
> does fix it, chances are it'll get broken again. I believe that
> the concept of all*config is a fundamentally broken concept for an
> architecture with numerous platform configurations.)
what about providing a reasonable (not necessarily useful)
configuration for a minimal arm setup (maybe for each endianess)
and one for a maximal (read: as many as possible) options
selected which - and this is the important part - are known
and supposed to compile (regardless if they make sense or are
used in actual systems)?
this would allow regression tests, which in turn, might provide
valuable info about the involved subsystems, for both tollchain
and arm folks ...
if this isn't in _your_ interest, then maybe some specific
(considered representative) system defaults can be used instead
best,
Herbert
> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
> 2.6 Serial core
> -
> 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/
On Mon, 13 Sep 2004, Herbert Poetzl wrote:
> On Mon, Sep 13, 2004 at 07:51:19PM +0100, Russell King wrote:
> > Basically, there's a fair amount of conditions under which Kconfig
> > fails to perform reasonably, and these (little used) targets are
> > an example of that.
> >
> > If you want something that's guaranteed to work, use one of the
> > per-platform default configurations. Nothing else carries any
> > guarantee what so ever on ARM.
> >
> > (Also, I have no interest in all*config myself so even if someone
> > does fix it, chances are it'll get broken again. I believe that
> > the concept of all*config is a fundamentally broken concept for an
> > architecture with numerous platform configurations.)
>
> what about providing a reasonable (not necessarily useful)
> configuration for a minimal arm setup (maybe for each endianess)
> and one for a maximal (read: as many as possible) options
> selected which - and this is the important part - are known
> and supposed to compile (regardless if they make sense or are
> used in actual systems)?
See arch/arm/configs/* for many configuration examples. They are all
separate ARM targets and usually a given config enables as much
sensible options
as possible for that target. It seems to me that using
'make neponset_defconfig && make all' is a relatively good configuration
to test toolchain regressions, at least for an ARMv4 build.
If you need, say, a minimal test configurations with the least selected
options as possible, I don't think anyone would object including such a
default config file.
> if this isn't in _your_ interest, then maybe some specific
> (considered representative) system defaults can be used instead
Right.
Nicolas
On Mon, Sep 13, 2004 at 09:29:00PM +0200, Herbert Poetzl wrote:
> if this isn't in _your_ interest, then maybe some specific
> (considered representative) system defaults can be used instead
The RiscPC machine is a representative set of defaults. It just
doesn't happen to work with all*config because all*config makes
no sense.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> If you want something that's guaranteed to work, use one of the
> per-platform default configurations. Nothing else carries any
> guarantee what so ever on ARM.
I did give that a shot, but every one I tried seemed to be
broken. (I may have been using a too-new compiler, and I probably
suffer from impatient newbie-itis.) Can you suggest which commands
to use to retrieve a working default configuration?
Thanks,
Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
On Mon, Sep 13, 2004 at 06:42:38PM -0700, Dan Kegel wrote:
> Russell King wrote:
> > If you want something that's guaranteed to work, use one of the
> > per-platform default configurations. Nothing else carries any
> > guarantee what so ever on ARM.
>
> I did give that a shot, but every one I tried seemed to be
> broken. (I may have been using a too-new compiler, and I probably
> suffer from impatient newbie-itis.) Can you suggest which commands
> to use to retrieve a working default configuration?
Obviously I can't comment on the problems you're seeing with those due
to the lack of details. However, last time I built a pure bk-based
tree (4 days ago), the following worked:
- ebsa110
- netwinder
- imx
- integrator
- lubbock
- rpc
- s3c2410
- versatile
However, many of these have sub-classes of either cpus or machines,
and running allnoconfig against these will again generate invalid
configurations.
So:
$ make netwinder_defconfig
$ make
will build a working kernel.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
> last time I built a pure bk-based tree (4 days ago), the following worked:
>
> - ebsa110
> - netwinder
> - imx
> - integrator
> - lubbock
> - rpc
> - s3c2410
> - versatile
>
> ... So
> $ make netwinder_defconfig
> $ make
>
> will build a working kernel.
OK, I've given up entirely on allnoconfig, and simply ran 'make netwinder_defconfig'
once by hand to capture a working arm config file
(since I already lug around config files). This lets me avoid special-casing arm,
and seems to work ok.
Sorry for the noise.
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change