login
Search
[ Continuation on the "ARM MSM updates" thread ] Yeah, the thread started out as a "I got really bored with lots of msm patches", and then just expanded into what I think is wrong with the I can understand that, but at the same time, I do think that the "defconfig" file concept as it is now is just broken. To the point of being unfixable. It's obviously just a copy of the final .config, and it's fundamentally not really readable (and especially not writable) by humans. And that all actually made some sense way-back-when, back when it was originally done - back when our config files were tiny (compared to what they are now), and when it ended up being the default input for the config. It just doesn't make much sense any more. The Kconfig files themselves end up having defaults for the core things, and the non-core things are too many to list/edit sanely in that format. So the original reason I want to remove them is that they are very annoying, but the reasoning that then takes that annoyance and makes me think seriously about removing them despite the inevitable pain factor is that I really don't think we can even use the concept for any better model. Anything better would _have_ to be totally different. And no, I don't think your "diffs against a base" model work either, because while it would make them smaller, it would still make them basically unreadable and uneditable by any human, which means that it's not something we should check in - it's a generated file! And I do think our kernel configurator language already should basically have the expressive power to do it *sanely*. We already support including other files, which is a requirement for any hierarchical model. So I _think_ whatever "mach-xyz" file _should_ do something like # Kconfig file for OMAP4ABCXYZ chip .. set the particulars for this _particular_ chip, ie select the particular drivers on this chip .. include "chip-family-details" (ie maybe "base OMAP ...
Some of this work has been already done like I responded in the other thread. So we could use the current omap3_defconfig for omap2, 3 & 4 with some more work. Then do the same thing for omap1. That would cut it down by total of 38 defconfigs. Compiling in multiple ARM platforms is trickier, we would have to get rid of the duplicate defines like NR_IRQS, then have some common clock framework etc. Then figure out some way to get rid of Makefile.boot. Russell probably has some other things in mind that would have to be Whenever you feel like it, please just go ahead and do: $ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm That way maybe you can wait a bit longer for the other defconfigs and as an extra bonus I won't get flamed for removing these omap defconfigs ;) Tony --
- Find someway to handle the wide variety of interrupt controllers. - Be able to handle any multitude of V:P translations, including non-linear alongside linear transations. - Different PAGE_OFFSETs - Different kernel VM layouts allowing for a variety of different ioremap region sizes Note that Linus is talking about removing all but one or two ARM defconfigs - which means your omap3_defconfig will probably be eventually culled. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
Some of these could be handled by allowing building a seprate instance for each platform compiled in. Maybe we could set them up with symlinks. How about a minimal generic relocatable ARM kernel and then we load the Yes but I also think we need to do something about this. Regards, Tony --
Some effort is being deployed at my $job to do that. Initially only the linear translation will be supported, which should cover the vast majority of the cases already. The odd targets will simply require a VMALLOC_END should only need to become a per machine class variable We already have runtime selectable machine instances. Building multiple Like I said, there is an effort to gradually overcome those issues one by one. Nicolas --
Unfortunately the same time we are slowly adding more and more ifdef else code that adds new blockers to compile in multiple ARM platforms into the same kernel. Some of the ones I've ran into over past few months are CONFIG_HAS_TLS_REG, CONFIG_VFPv3 and CONFIG_SMP. The first two are fixable though. Anyways, once we get the TLS and VFPv3 issues sorted out, we can do ARMv6 and ARMv7 booting binaries so I'll be able to whine about any new blockers getting added :) Regards, Tony --
- Support for ARMv5, v6 and v7 in the same kernel image. On davinci, we've recently run into the problem where a new SoC in the family is largely the same in terms of common HW blocks ands shared peripherals with other davincis, but they upgraded from ARMv5 to ARMv6. Attempting to build a single kernel that supports ARMv5 and ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in the same kernel. Kevin --
Yeah we should sort that out, otherwise more things are slowly added that makes it harder to do. Regards, Tony --
Ok so multiple platforms in one kernel is a different subject and could warrant a different thread. However it's interesting because we do that quite well on powerpc :-) (Note also that while the device-tree helps make it even easier, it's We have a very nice and simple interrupt mapping scheme on powerpc that makes that quite trivial along with the generic irq changes that went in a couple of years ago (which we mostly based on ARM iirc). We have a structure that define an interrupt numbering domain (which can be associated 1:1 with a given controller but doesn't have to), and simple APIs to allocate "linux" interrupt numbers associated with a given domain/HW number pair. From there, we support multiple domains, For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic patching would do nicely here though it's problematic with XIP kernels Does this have to be a per SoC or mach family ? Users can change PAGE_OFFSET on powerpc to change the user/kernel split (for example in order to get more ioremap space or avoid turning on HIGHMEM) but it's in the domain of the config and a kernel with a lower PAGE_OFFSET can always boot all platforms even those that don't require it. Alternatively, you can always try to do like we do on ppc64 with fully Cheers, Ben. --
Thanks for all the good info, that will be handy when trying to figure out how to change things to support multiple ARM platforms. Regards, Tony --
On Fri, Jun 4, 2010 at 03:02, Benjamin Herrenschmidt
Supporting multiple platforms matters a lot to keep everything (not
just defconfigs)
under control.
Technically, on m68k we only need two defconfigs: sun3_defconfig (Sun 3 doesn't
use a Motorola MMU) and multi_defconfig (which is the logical OR of
all the other
defconfigs, and which should work on all non-Sun 3).
The reason we have the others is to ease building of platform-specific
kernels that
need less memory. I guess most of them can be (almost) regenerated from
So you could easily have one big common defconfig...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Ah, I forgot...
But indeed, most of the churn when updating the defconfigs (hmm, it's
been a while I submitted an
update) is in the non-arch part: disabling zillions of new options we
don't want.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
Well, there are things we still don't allow in one binary, and I suspect it would be nasty on ARM too, such as widely different core arch (which in ARM land would translate into widely different ARM architecture version). But yeah, we can pretty much make giant defconfigs. They are not very useful tho. In the embedded world, size constraints are quite strong and so you really need to be able to target only the subset of things you want for some types of devices. Of course, for things like ARM netbooks, it would be nice to have one giant defconfig that boots them all, and that's probably an achievable goal if the variants between bootloaders can be sorted out. Cheers, Ben. --
Have you noticed this .. http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130 I'm not sure of the goals, but it sounds like it might be relevant. Daniel --
In some cases you don't want to automatically enable features but rather fix the Kconfig file. For example, with the select dependencies patch (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the following: warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects CPU_32v6K which has unmet direct dependencies (CPU_V6) Unless I misunderstand this, a solver may try to select CPU_V6 which I don't want to. The solution is to fix Kconfig as below: Author: Catalin Marinas <catalin.marinas@arm.com> Date: Wed Aug 12 13:50:05 2009 +0100 Mark CPU_32v6K as depended on CPU_V7 Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 9f10a9b..a4909db 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -398,7 +398,7 @@ config CPU_V6 # ARMv6k config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP - depends on CPU_V6 + depends on CPU_V6 || CPU_V7 default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) help Say Y here if your ARMv6 processor supports the 'K' extension. -- Catalin --
It seems like those are something the solver would likely find, or have problems with. Since we technically don't have a solver yet it's hard to say what the end result would be. None the less it's sucks we have things getting selected without their depends be met or correct.. Daniel --
Umm. I don't think you've actually looked at the Kconfig files if you're writing this, because that's precisely what we already do. arch/arm/Kconfig has a big choice statement in it to select the machine class, and then it sources the individual arch/arm/*/Kconfig files, which are themselves wrapped in a if FOO foo's options endif It's not one huge big "let's source everything and hope people ignore options which don't apply to their platform" that you seem to be implying we are doing. The big problem with doing away with the defconfig files is more to do with what happens _outside_ of arch/arm. At one time, I was phasing IDE out, and didn't want to see the "IDE" configuration options on platforms which either never had IDE support or had had IDE support removed - unfortunately I was overruled by the IDE/ATA developers and the conditionals we had went away. That's just one instance, but consider when you're presented with thousands of driver and filesystem configuration options as is the case with modern kernels. How do you find the few options you need to get to a point that the kernel you've built is actually useful? Anyway, I thought we were discussing _defconfig_ files, not Kconfig files... What we _could_ to is introduce a: config STD_CONFIG bool "Enable me to generate a standard configuration for your platform" and then have platforms conditionally select everything that's appropriate for their use. That provides a way to avoid the ages old issue of select forcing options on, but the user still being presented with the option and being told the only possible value for it is 'y'. And yes, it _is_ necessary - because if you want to turn off something on the platform - eg, you're not using MMC and MMC fails to build - you can still end up with a working configuration at the end of the day. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
Check out the SAT solver link I quoted in the prior email.. That sounds like a really interesting solution. The defconfigs would ultimately hold just what's unique to a given board, then the solver would figure out what to else to enable just from those unique properties. So we would still have defconfigs , but they would not have loads of duplication like they do now. I don't see how we can do without defconfigs altogether tho. I mean , if you want to run a Beagle board or a Nexus one we can't just give the users a slim ARM config and let them troll through 1000's of drivers trying to find just those ones that work on their given board. Daniel --
Well, you also don't need the full defconfig's with the kernel. Right now they are just noise. They actually _hide_ things, because diffstat (and dirstat) information becomes pointless, and the diffs become totally unreadable by any human (trust me - when the choice is between "search for next relevant diff" or "blast it, I can't be bothered with walking through this crap", quite often the choice is the latter). So they are an actual burden on real development. Linus --
BTW, can't we switch to processing them with cpp? That'd cut down on the churn big way, AFAICS, not to mention reducing the odds of missing some of them on such changes, etc. --
That's true. We already have things like KCONFIG_ALLCONFIG for these purposes, and that's primarily what I use for buildig bootable randconfigs for specific board/CPU combinations on SH. --
Hello, [Added linux-arm-kernel ML to Cc, note that it's moderated for non-subscribers.] I wrote a script that throws out all unneeded lines in all arm defconfigs that don't influence the resulting .config for .34 and .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced. Here are the results: $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm 11.8% arch/arm/configs/ 10.0% arch/arm/mach-msm/ 10.8% arch/arm/mach-omap2/ 4.8% arch/arm/mach-pxa/ 4.5% arch/arm/mach-s5pc100/ 3.3% arch/arm/mach-s5pv210/ 4.4% arch/arm/mach-spear3xx/ 3.1% arch/arm/mach-ux500/ 5.1% arch/arm/plat-s5pc1xx/ 3.1% arch/arm/plat-samsung/ 38.2% arch/arm/ $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm 3.1% arch/arm/mach-davinci/ 11.3% arch/arm/mach-msm/ 12.2% arch/arm/mach-omap2/ 5.4% arch/arm/mach-pxa/ 5.1% arch/arm/mach-s5pc100/ 3.7% arch/arm/mach-s5pv210/ 5.0% arch/arm/mach-spear3xx/ 3.5% arch/arm/mach-ux500/ 5.8% arch/arm/plat-s5pc1xx/ 3.5% arch/arm/plat-samsung/ 40.9% arch/arm/ $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config 1.1% arch/arm/configs/ $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1 177 files changed, 652 insertions(+), 194157 deletions(-) (The insertions above are only moved lines I think, I didn't check them all.) The branches arm/defconfig/reduced-v2.6.34 and arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at http://git.pengutronix.de/?p=ukl/linux-2.6.git) So maintaining these minimal defconfigs would have reduced the defconfig noise from 11.8% down to 1.1%. And probably it could be considerably reduced further with constructs like: config HAVE_MTD_NAND_MXC bool config MTD_NAND_MXC tristate "MXC NAND support" ... default m if ...
Hi Linus, I think my mail hit your inbox during your vacation. As this is quite important for the ARM people and there isn't much time left, can you please comment? Thanks in advance Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
Hi Linus, As you havn't replied up to now I wonder if that just means that you still plan to remove all defconfig files or if you are just busy doing other things. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
The reason I haven't replied is that
(a) I don't think this really "solves" the issue, in that the
resulting files still aren't human-readable, and as such I suspect it
doesn't solve the problem in the long run: people will continue to
just run "make config" and then copy the resulting .config file as a
defconfig file.
and
(b) even if ARM were to go this way, and run the scripts to minimize
the defconfig files, that's not something _I_ would do. If I get tired
of seeing the insane pull requests where 90% of the crap is just
defconfig noise, then _my_ solution will be to remove the crap because
I simply am never going to be the person who maintains those defconfig
files.
See? Especially the "(b)" part is relevant - I am simply not going to
be the person who tries to clean up after other people sh*tting all
over their trees with defconfig files. If I do something, it will be
total surgery, ie "keep your damn broken defconfig files somewhere
else than in my tree - I'm tired of your stupidities". It will not be
"I'll be your mother and clean up your room every day after you made a
mess".
So if the ARM people decide that your script is a good way to clean up
the mess, I might be happy with that. But that would require that they
NEVER EVER try to push me a update that contains an un-cleaned-up
defconfig file. If they do, and the defconfig files end up showing up
big in git history, then the approach has failed.
See? The reason I'm not replying to your approach is that it's simply
not for me to do so (and no, I don't think it's maintainable, but I
haven't tried it, so..)
Linus
--
Does this mean that you aren't going to delete all the defconfigs during the next merge window if we come up with an alternative solution to yours? When you brought up the problem you seemed absolutely convinced that nothing except your solution was going to be acceptable. --
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
That's not true. What's true is that you didn't seem to _understand_
my solution, so I tried to push the understanding of it.
There are always other solutions. I seriously doubt that Uwe's is a
maintainable one. That said, even a one-time "reduce the size of that
stinking pile of sh*t" is probably better than nothing.
I hope you at least do agree that the current situation is a steaming
pile of sh*t. And yes, I _will_ remove the crap, both from POWER and
ARM, unless I see some serious tries at fixing it.
Linus
--
Hello Linus,
I'm willing to try my solution, some others on the linux-arm-kernel
lists considered it worth trying, too. Feel free to pull my tree[1].
Russell refused to take defconfig changes for a while now, so I don't
expect merge problems if you do.
If it helps the powerpc people I can reduce their defconfigs, too.
Best regards
Uwe
[1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1
Uwe Kleine-König (1):
ARM: reduce defconfigs
arch/arm/configs/acs5k_defconfig | 1146 --------------
arch/arm/configs/acs5k_tiny_defconfig | 860 ----------
arch/arm/configs/afeb9260_defconfig | 1157 +--------------
arch/arm/configs/am200epdkit_defconfig | 1044 +------------
arch/arm/configs/am3517_evm_defconfig | 1250 ---------------
arch/arm/configs/ams_delta_defconfig | 1224 +--------------
arch/arm/configs/ap4evb_defconfig | 722 ---------
arch/arm/configs/assabet_defconfig | 862 +----------
arch/arm/configs/at572d940hfek_defconfig | 1318 +---------------
arch/arm/configs/at91cap9adk_defconfig | 1107 +-------------
arch/arm/configs/at91rm9200dk_defconfig | 955 +-----------
arch/arm/configs/at91rm9200ek_defconfig | 942 +-----------
arch/arm/configs/at91sam9260ek_defconfig | 958 +-----------
arch/arm/configs/at91sam9261ek_defconfig | 1087 +-------------
arch/arm/configs/at91sam9263ek_defconfig | 1103 +-------------
arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------
arch/arm/configs/at91sam9rlek_defconfig | 864 +----------
arch/arm/configs/ateb9200_defconfig | 1222 +--------------
arch/arm/configs/badge4_defconfig | 1178 +--------------
arch/arm/configs/bcmring_defconfig ...Well, I can hardly refuse a pull that removes almost 200k lines. So
I'd happily pull it. Just this single line in your email is a very
However, before I would pull, I'd definitely like to make sure we at
least have some way forward too, and clarify some issues. So I have a
couple of questions:
- is this guaranteed to be a no-op as things stand now, and what are
the secondary effects of it?
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
window itself when things are in flux. However, while it would be a
good time to pull this for that reason, it's also a _horrible_ time to
pull if it then regresses the defconfig uses, or if it causes horrible
problems for linux-next merging etc.
- what happens when somebody wants to update the defconfig files?
This is a question that involves a number of people, because over
the last half year, we've had lots of people changing them. "git
shortlog -ns" on that ARM config directory gives 39 people in the last
half year, with the top looking roughly like
26 Ben Dooks
10 Tony Lindgren
4 Haojian Zhuang
4 Kukjin Kim
3 Santosh Shilimkar
3 Sriram
2 Janusz Krzysztofik
....
and how are these people going to do their updates going forward
without re-introducing the noise?
IOW, I'd _love_ to get rid of almost 200k lines of noise and your
approach would seem to have the advantage that it's "invisible" to
users. But I would want to get some kind of assurance that it's
practical to do so.
Linus
--
This cannot be any worse than wholesale removal of those files as you were contemplating at some point. Furthermore, on ARM we have someone providing automatic rebuild of all defconfigs already, so any serious I think Uwe could provide his script and add it to the kernel tree. Then all architectures could benefit from it. Having the defconfig files contain only those options which are different from the defaults is certainly more readable, even on x86. Nicolas --
You aren't really answering the question. The thing is, the wholesale
removal wouldn't happen during the late -rc anyway, and it wouldn't
cause any merge issues (merge conflicts where the file is just to be
removed are trivial to take care of).
So I'm really asking about the issue of "how does this work during the
late -rc phase". Where the _timing_ is the important thing.
Because I could as easily pull after 2.6.35 is out. That has it's own
downsides (with all the merging going on), but at the same time, it's
clearly the right time for a large change.
So when I ask about timing and "how does this work in late -rc", it's
really about how safe it is to do now. Because if it isn't very
obviously safe, I can't pull it.
One part of the "obviously safe" thing is verification for each
defconfig file that the end result is identical with the reduced
version. Uwe implied that it was, and that was clearly the intention,
but was there some explicit verification that yes, the
before-and-after configurations are 100% the same?
Also, I assume that while it's _mostly_ a transparent change to users,
it does require that people do "make oldconfig" with the reduced
defconfig file first, in order to avoid having to answer with the
defaults. No? And the reduced defconfig files obviously do depend on
the default in the Kconfig files themselves, so it does have that kind
of fairly subtle semantic change that may not be entirely obvious or
easy to notice.
So from a timing standpoint, I just want to be convinced that "late
-rc" really is the right thing. I'm not entirely sure it is, even
Quite possible. But maintainers would need to be on the lookout of
people actually using the script, and refusing to apply patches that
re-introduce the whole big thing.
I also haven't actually seen the script - I don't think Uwe ever
posted it - so maybe it's some very fragile thing. Hard to judge on no
real information ;^p
Linus
--
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds I can (partially) speak for powerpc. If ARM uses this approach, then I think we can do the same. After the defconfigs are trimmed, I certainly won't pick up any more full defconfigs. Of course, I'm also operating under the assumption that this is a temporary measure until one of the better solutions is implemented. I do suspect that the trimmed defconfigs will tend to be unstable and will still require manual maintenance. I think the Kconfig fragments approach is the most promising if the dependencies issue can be solved. g. --
Hi I just restarted my script on the powerpc defconfigs basing on rc5, I I don't understand what you mean with unstable here. They are sensible to changed defaults in the Kconfig files which you can consider to be good or bad. And ack, I like the Kconfig approach, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
Hello, So Stephen was faster than me. I don't know yet how he optimised my script, meanwhile I put some efforts into it, too by just checking lines that match "^(# )?CONFIG_". Find it attached. I will start to reduce the remaining configs (i.e. all but arm and powerpc). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
I added just a simple heuristic: If I could remove a line, I attempted
to remove twice the amount next time around (and fall back to 1 if it failed).
I.e. main loop:
i = 0
lines = 1
while i < len(config):
print 'test for %r + %d' % (config[i], lines)
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + lines:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i:i+lines]
lines *= 2
else:
if lines > 1:
lines = 1
else:
i += 1
I didn't measure what the actual improvement was, but I saw a fair amount
of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting
the resulting patch though. :P
While this script is great, it is somewhat painful to run given that it
attempts one config per line. Even on a fast machine that tends to take
a while.
-Olof
--
The optimal solution is to add that .config reduction ability straight into the Kconfig parser (scripts/kconfig/*). There you can find out right away what are the non default state for each config option without actually trying them out one by one. Nicolas
With the trimmed config, changes to default settings on config items will immediately picked up regardless of whether or not it was wanted, and potentially disabling things that were explicitly selected in defconfig. But thinking about it more, that isn't really any worse than the old situation where defconfigs always override Kconfig Yeah, the problem goes away with Kconfig fragments. A programmer can then explicitly state which CONFIG values need to be overridden. g. --
Hi Linus, I hoped you to pull this in during the merge window, but doing it now is I'm pretty sure it's 100% save as I only kick a line in the defconfig if the result doesn't change. Well, modulo bugs in my script. But now See attachment. It's just: for each line: kick $line if $(make ..._defconfig) results in the same config without $line Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
I'll answer for myself only. Others are free to pitch in if they have a different opinion. Since this issue came up, RMK refused to merge any changes to the arch/arm/configs directory. Therefore a lot of those files aren't quite up to date anymore anyway. We simply skipped the usual defconfig updates that used to be sent around -rc4. And that's for the few defconfig files that people cared to update. A bunch of less frequently used targets are probably out of date since many kernel versions ago. Those files are mainly used as a convenience for build testing. We tend to cram as many profiles together as we can to limit the number of different test builds. The remaining files are (supposed to be) incompatible configurations. So I doubt anyone is using them verbatim for deployed systems. If anything they should be reference Given what I said above, I think that: 1) Those files aren't critical. They're damn useful indeed, but a glitch in a defconfig file is far from being as important as a glitch in the very code they refer to. So I don't think this is all that critical if the pull is applied late in the -rc period. 2) Doing it sooner rather than later is IMHO the best thing to do. At least we could now focus on maintaining and even improving on that state rather than going on in circles wondering what to do with it. People would be able to think about how to update their defconfig files in the new form now instead of simply not updating it at all as it has been the case for a while until something happens. So to me this is all in favor for a merge before next merge window. As I said above, those files aren't that critical and no one should end up in trouble if something is not exactly right after this merge. So I do too. At least this is positive progress for some bad issue that no Pretty easy to see on the diffstat graph. Anyway, I'm sure once the script is available then an army of kernel ...
We all agree this is a pile of sh*t, as the truly valuable data is drawned down into it. The diffstat numbers below certainly shows it rather clearly. Linus, please pull this git tree. This should functionally be a no op,
BTW, looking at the most common entries in there, I think we might at some
point want to change some of the defaults in the respective Kconfig files.
Right now an empty defconfig would result in a configuration without
file system, networking or modules:
sort arch/arm/configs/* | uniq -c | sort -n | tail -n 30
114 CONFIG_BLK_DEV_RAM=y
116 CONFIG_BLK_DEV_INITRD=y
116 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
117 CONFIG_NFS_FS=y
118 CONFIG_MTD_CHAR=y
119 CONFIG_INOTIFY=y
122 # CONFIG_BLK_DEV_BSG is not set
122 CONFIG_IP_PNP=y
123 # CONFIG_IPV6 is not set
123 CONFIG_MTD_BLOCK=y
125 CONFIG_FPE_NWFPE=y
127 CONFIG_NET_ETHERNET=y
128 CONFIG_LOG_BUF_SHIFT=14
128 CONFIG_MTD=y
131 CONFIG_PACKET=y
132 # CONFIG_INPUT_MOUSE is not set
133 CONFIG_DEBUG_KERNEL=y
134 CONFIG_EXT2_FS=y
138 CONFIG_MODULE_UNLOAD=y
139 CONFIG_TMPFS=y
142 CONFIG_NETDEVICES=y
147 CONFIG_ZBOOT_ROM_BSS=0x0
147 CONFIG_ZBOOT_ROM_TEXT=0x0
151 CONFIG_INET=y
151 CONFIG_UNIX=y
153 CONFIG_NET=y
156 # CONFIG_VGA_CONSOLE is not set
158 CONFIG_MODULES=y
164 CONFIG_SYSVIPC=y
174 CONFIG_EXPERIMENTAL=y
Also, some of the defconfigs contain stuff that arguably does not belong
into a defconfig and could be removed in the next merge window, e.g.
ezx_defconfig:CONFIG_LOCALVERSION="-ezx200910312315"
pnx4008_defconfig:CONFIG_DECNET=m
at572d940hfek_defconfig:CONFIG_SGI_PARTITION=y
Arnd
--
We need to come up with a scheme that allows for expressing the most likely options you might want if you have machine x and/or machine y selected. Those likely options are for drivers corresponding to hardware soldered on the board or integrated into a SOC and therefore which is not "optional". Right now this information is carried in the defconfig files. Without that you need to lookup various datasheets and wade through thousands of Kconfig options. Compared to that, stuff like filesystems and networking protocols are optional items that currently are more arbitrarily included into or excluded from the defconfig files. I think that the first category of options should automatically be selected on a per machine basis depending on BASE_CONFIG or the like and expressed directly in the Kconfig files. Typically there are very few of those (like a dozen or so for some example target I looked at). Nicolas
Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Thanks, David --
Uwe posted it earlier in this thread as an attachement, and I put the
python script into the merge commit message too. And we should
probably put it somewhere in scripts too, and/or make a 'make' target
to create the small config files.
I pushed it all out, and tagged it as -rc5.
Linus
--
Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. David --
I'm sure that some clever people will come up with a better script eventually. Maybe this could even be generated by scripts/kconfig/conf directly. Nicolas --
Yes, I think there's a more efficient way to do it, but it would require the SAT resolver, or something like that. -- Felipe Contreras --
Note that no kernel is built at all, only the config is regenerated once for each line. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
You could special case blank lines and comments (other than ones like "# CONFIG_FOO is not set" which do matter). They account for ~15% of the lines in my .config files. But it probably doesn't matter all that much. I just ran reduce_defconfig in parallel on all the ia64 defconfig files (in separate build trees) and they were all done when I looked back an hour or so later. Nice tool! -Tony --
FYI, I repeatedly submitted a bash script to do this back in 2005, with documentation and makefile changes to call it and so on. http://lwn.net/Articles/161086/ The current version of that script is is in my mercurial archive here: http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh I'm still using it in my Aboriginal Linux project. (Not just for the kernel, but for busybox and uClibc too.) Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is trying to build kernels aimed at every qemu system emulation. I've got maybe 2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...) They're used to create the system-image tarballs here: http://impactlinux.com/aboriginal/downloads/binaries/ You can download that for that target that interests you, extract it, and use run-emulator.sh to launch it under qemu. I have a cron job that does cross- platform regression testing, spitting /dev/console to a log file on the host. By the way, my build is generating those miniconfigs via a common "baseconfig" file to which I append the target-specific stuff. For example, my current baseconfig is: CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y Then for mips I ...
That's your point of view. My viewpoint was that I had read your email, thought of some alternative solution, proposed it and the result was shot down without any apparant thought about it. That gave the impression that you _only_ wanted to see your own solution. The result of that has been very little in the way of progress towards either your, or my alternative solutions - and apart from a few Kconfig corner quirk patches, the only major work that's happened has been from Uwe. So in that regard, I support Uwe's patches as a means to prevent the impending loss of build coverage from facilities such as linux-next and the ARM kernel autobuilder, as that's the only option that's currently available. As far as timing goes, I see no reason for it to be merged during -rc. As has already been said, I'm intending _not_ to make the defconfig situation any worse by accepting patches which add to the mess, as I'm also mindful that its exactly those kinds of patches are the cause of this problem. Now, I'm happy to take Uwe's tree through mine for the next merge window _iff_ you find his solution acceptable, and you want that to happen. I'll also use this opportunity to warn you now - especially as you also complained about the amount of churn. There is an effort to try to allow a single ARM kernel to boot on a wider range of platforms with more differences than it currently does. This is going to mean a certain amount of restructuring, and a lot of additional patches over time to gradually convert the code. So, I'm expecting that there will be even _more_ patches - some fairly big - to come over the next year or so. To give an idea - if we change the structure which defines a machine's properties, we're going to be changing 348 files under arch/arm to match. Clearly that's also going to give you a problem with diffstat being swamped. --
OK, please let's put this appearance of misunderstanding behind. For the record, I do support Uwe's work too. I do wish it could go in now so that from that point going forward we could only focus on improving the thing instead of having to care about implications during the merge window. But I do prefer RMK's proposal in the long run. Not only is it more expressive and clear, but it is easier to maintain going forward too. But that transition cannot be automated and I doubt the majority of targets will be converted anytime soon if at all. So at least Uwe's reduction is quite a good compromise for those. Nicolas --
Ok, I merged it. I do love the diffstat. And while it may not be
optimal or a final solution, nobody seems to hate it either.
Linus
--
On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux I think you got it wrong. Linus liked my proposal of minimal defconfigs, and the only discrepancy was on the format: http://article.gmane.org/gmane.linux.kernel/995419 -- Felipe Contreras --
Well, Linus does have a point - I can't start a new with Kconfig and generate a working defconfig first time mainly because of the thounds of options there. What I can do is get the ARM side of the configuration right, since for the majority of cases the only thing that needs doing is selecting the platform class and the board itself. The problem comes with driver configuration, where you have to go through lots of menus to find all the drivers for the platform/SoC. That's the tedious bit, and more often than not it takes several attempts to get everything that's necessary. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
It's often tedious for other cases too ("I just want to enable a particular driver, what do I need to do so?"), and I do agree with Daniel that the SAT solver approach sounds interesting as a way to solve some of the complexities. At the same time, "SAT solver" does scream "over-engineering failure" to me. We've had horribly bad experiences with over-engineering in that space before. Yes, I know about MiniSAT and that these things can be done without necessarily huge amounts of complex code, but these things tend to grow to huge monsters. Who knows. Linus --
Would the resulting kconfig files that Linus is proposing (or whatever else goes in) be stable enough across different kernel versions that the hardware vendors could create them when the hardware is created and make them available? I'm not just thinking the ARM embedded space here, I'm also thinking things like laptops/notebooks which tend to have some unusual hardware as well. having a 'this is enough to see everything on the system' config would be a wonderful starting place to have. David Lang --
.. but if you do this _right_, then the defconfig files would be unnecessary. That's my point. If you are right, then I can remove the defconfig files entirely. Are you ready for that? And if you aren't ready for that, then what was the point of your email? Linus --
Linus, don't make this personal. The problem is NOT "what options which are found under the arch/arm tree do I need". The problem is "what options throughout the rest of the kernel do I need to result in a usable kernel". No amount of reorganising the Kconfig files into a heirarchial manner (which they already are) helps. Not one bit. Because they already are. That's not where the problem is. For instance, if I have platform A, I know it has an RTC. How do I know which of the 37 RTC drivers the kernel configuration presents me with to select? Am I really expected to open up the platform and read the device numbers off all the chips (some of which being surface mount are abbreviated) and work out that it's a TWL4030 RTC that I should be using? That's just one instance - and there's probably many more just like that. Just look at "multifunction drivers" for another case in point. How the hell do I know what multifunction driver is appropriate for a platform? Ditto "Power supply support". The list goes endlessly on. All those things I've mentioned are all _outside_ of arch/arm. That's where the _real_ problem is. Solve that problem so that it's easier for people to configure the kernel, and then we don't need the multitude defconfig files. That's the problem which the defconfigs are solving today. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
I don't think you read the whole thread. Earlier on, I explained exactly what I wanted: just add some "select" statements to pickt he things you need per the particular target configuration. You seem to have missed that part. In other words, you _can_ encode the information that is in the xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do it in a human-readable manner. And the hierarchical thing is absolutely required for that - otherwise you'd end up with just another form of the current xyz_defconfig. See? In other words, you should be able to basically use "make allnoconfig" together with a Kconfig.xyz file input to select _exactly_ the pieces you need, and nothing else. Linus --
Isn't that _also_ what I suggested with one modification - which was based on your suggestion with a _bit_ _more_ _thought_? Oddly that suggestion which you appear to have completely ignored - but clearly you did get the mail because you quoted a few lines from it in one of your subsequent replies - was based on your very idea. The one which you said "what was the point of your mail". Maybe the point is to discuss issues. You know, it's exceedingly difficult to discuss things if the other side doesn't read messages they're sent. Ergo, I don't think there's any point discussing this any further; you've crystal clearly already stopped listening. Maybe you should go back to that one which you gave such a flippant reply to and re-read it, and actually productively comment on my additional suggestion to yours? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
If you did this for drivers, what about disabling a driver? If we used "select" wouldn't that force all the drivers on without allowing it to be unselected? Daniel --
I already covered that in my (ignored) email where I brought up a "STD_CONFIG" config symbol, which could be disabled to turn off all these additional "select"s. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
I didn't ignore it, I guess I just didn't fully understand it .. So your saying it would drop all the selects, but keep the selected options in tact? Or it would just turn off all the selected options? Daniel --
config MACH_HALIBUT bool "Halibut Board (QCT SURF7201A)" select I2C if STD_CONFIG select I2C_WHATEVER if STD_CONFIG ... That means if you enable STD_CONFIG, you'll get everything that's required selected. If you then disable STD_CONFIG, I believe Kconfig leaves everything that was selected as still being selected. So, what you _could_ do is start off with a blank configuration, then configure a kernel with STD_CONFIG enabled and you end up with everything that's required. If you then want to disable something that's selected, turn off STD_CONFIG first, and you'll be able to turn off individual options. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
I just did a little test, and it doesn't. Kconfig would un-select all If my test was correct we would need a new "select" variant that would leave the options turned on in order to get something equal to the current defconfigs. Daniel --
That's because it knows what the original state of the symbol is. Yes, that's a little undesirable for our behaviour - but it can be worked around - by saving and restarting Kconfig. Try this: config STD_CONFIG bool "Standard config" default y config DRIVER_A tristate "Driver A" config ARM def_bool y select DRIVER_A if STD_CONFIG and in a new directory /path/to/kernel/scripts/kconfig/mconf test.conf If you turn off STD_CONFIG immediately, it'll turn off DRIVER_A. However, save out the config, and re-run mconf test.conf. You'll then find that DRIVER_A remains set even when STD_CONFIG is turned off. So, Kconfig does have the behaviour we desire but it's not directly accessible. Is it worth persuing? Will Linus accept this STD_CONFIG idea or did his lack of reply to it indicate that he's not something he's willing to entertain? In any case, this is my last mail on the subject. I won't be replying to mail for at least the next four days. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --
I think this certainly makes sense, at least as a proof of concept. If we end up with lots of select XYZ if STD_CONFIG then at that point it might be a good idea to introduce some variations in the Kconfig language directly. Something like a multi-priority select statement that would either: - provide the minimum amount of choice to the user and forcefully "select" a default set of options expected to enable all features of the target hardware, or - let the user see the "preselected" options with a chance to turn it off, but provide a y by default right away, or - ignore those "preselect" statement entirely, as some expert mode. Of course the 2nd and 3rd options wouldn't necessarily mean an optimal or even working kernel configuration would be produced. Nicolas --
The main problem with that approach is that you can't choose what is to be modules and what is to be built-in. Yes, I do -hate- modules as much as you do. However, I have for example that little ARM based NAS box (DNS-323 from Belkin) and the firmware on that thing won't let me boot a kernel that is more than about 1.5M, tho I have about 6M of flash to put an initramfs with modules in it. Maybe we could extend select that way. IE. A way to say that a given option should be y or m by default, for example, while the user can still change it to be the other way around ? Cheers, Ben. --
I apparently haven't explained myself enough, because what you keep on harping on is not something I consider acceptable. STD_CONFIG is pointless. It's pointless because the solution to what you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz file at all. So when I suggest special Kconfig files, they are meant to just generate the templates - ie they'd _generate_ what is currently the defconfig files. You wouldn't _have_ to use them at all. If you _had_ to use them, you'd lose the flexibility of Kconfig and asking questions. Linus --
Linus, I think somehow you and Russell are talking past each other. I must admit I don't exactly understand what your suggestion is all about. But I however think that Russell's suggestion makes tons of sense. Care to elaborate on what you dislike about it? What is this Kconfig.xyz you're talking about? How different is it from, say, arch/arm/mach-pxa/Kconfig? If you look into that file, you'll find a bunch of select's which are fundamentally needed for the given targets to boot. This file could be augmented with more conditional select's à la STD_CONFIG as Russell is advocating to actually provide defaults for the drivers that those targets should have by default. Sure. a standard "make config" would still produce that .defconfig as usual. Only that you'd have to turn STD_CONFIG off to be offered the choice of enabling/disabling those drivers which are enabled by default otherwise, just like the "make foo_defconfig" is doing now. Nicolas
To make this _really_ concrete, let me actually give you an example (but broken and pointless) example Kconfig file, in order to _avoid_ having a def_config file. I do it by generating it. Let's say that I want a x86 configuration that has USB enabled. I can basically _ask_ the Kconfig machinery to generate that with something like this: - create a "Mykconfig" file: config MYCONFIG bool default y select USB source arch/x86/Kconfig and then I just do KBUILD_KCONFIG=Mykconfig make allnoconfig and look what appears in the .config file. In fact, do this: make allnoconfig cp .config no-config KBUILD_KCONFIG=Mykconfig make allnoconfig cp .config my-config diff -u no-config my-config to see the point of it all. Now, the above is a _trivial_ one. And it's actually broken, because I should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). But with this approach you could basically generate the defconfig files. And exactly because Kconfig files are already hierarchical, you can do things like - Kconfig.omap3_evm: # Set the OMAP3 EVM-specific parts config OMAP3EVM bool default y select OMAP3_EVM_TIMERS # whatever ... # this sets the thngs all OMAP3 cases want source Kconfig.omap3 - Kconfig.omap3 # Set the OMAP3 specific parts config OMAP3 bool default y select USB_SUPPORT select USB ... source Kconfig.arm and now you'd be able to basically generate a OMAP3EVM .config file by just running "allnoconfig" on that Kconfig.omap3_evm file. But it would only have to select the parts that are specific for the EVM platform, because the generic OMAP3 support would be picked by the Kconfig.omap3 file, which in turn would not have to worry about the generic ARM parts etc. See? Linus --
(as one who just finishing updating powerpc defconfigs...) ditto here. I'd be happy to be rid of all the existing ppc defconfigs. I like the Kconfig approach, but to be useful (at least for me) there would need to be a way to get Kconfig to complain about things like broken selects as in your example. g. --
Still selects needs to be improved so we have a 'select_module' option that would make that driver a module instead of built-in. -- balbi DefectiveByDesign.org --
There was an attempt to fix this (I can re-post if people are interested): http://lkml.org/lkml/2009/9/16/413 -- Catalin --
I was looking at this new defconfig added this merge window, omap3_stalker_lks_defconig .. diff -u arch/arm/configs/omap3_defconfig arch/arm/configs/omap3_stalker_lks_defconfig | diffstat omap3_stalker_lks_defconfig | 850 +++++++------------------------------------- 1 file changed, 140 insertions(+), 710 deletions(-) There's a lot of stuff that's different in there .. If I look through it, there's stuff that's not related to OMAP , or even drivers. Like Kprobes gets disabled over omap3_defconfig . To me that's kind of messy .. It should really be just what the user absolutely needs. I think we're able to get away with that now cause no one cares enough to really read the defconfig and see what's going on. Having stuff like that adds more flux. Whatever scheme we go to would likely change that and people would actually read what's going on. So we wouldn't be able to randomly have Kprobes enabled in one config, and not enabled in another one. Or having a debug config as one, then having a performance config for another. Daniel --
How about instead of using full defconfigs, we use minimal ones and let the rest be determined with defaults. For example, omap3_beagle.baseconfig would have something like: CONFIG_MACH_OMAP3_BEAGLE=y CONFIG_ARCH_OMAP=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP3430=y CONFIG_AEABI=y CONFIG_EMBEDDED=y CONFIG_ARCH_OMAP_OTG=y CONFIG_OMAP_MUX=n CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_DM_TIMER=y CONFIG_INPUT_MOUSE=n You copy that to the .config, and then do: echo "" | make ARCH=arm oldconfig The result would be exactly the same as we have now. With the SAT resolver I think it should be possible to automatically simply the current defconfigs. (CC'ing Vegard for comments) I'm attaching a simplified base config, that I used to test this, and the result is an exact match of the current omap3_beagle_defconfig. -- Felipe Contreras
I wouldn't mind that either, but there needs to be some way to check that they _are_ minimal. Which is more complicated than even SAT, afaik. So the reason I don't like the "minimal defconfig" notion is that a "regular defconfig" will work equally well, and lazy people will thus not bother to make it minimal (because it's work) and instead just pick the full config output. And we're all lazy. So gearing the process towards something that makes it easy for lazy cases to do the wrong thing is a bad thing. We also don't have any way to "source" these config files from each other, so there's no way from within such a config file to say "use the basic omap3 defaults an then just add this on top". You can do it by concatenating several such files manually from the Makefile or whatever script, of course, but then you end up with the files themselves not actually describing what they do. That's why I suggested the Kconfig format instead. It's the exact same idea, but it's a "before pre-processing" format that already supports including other files. Linus --
On Sat, Jun 5, 2010 at 5:39 PM, Linus Torvalds I don't think so. The SAT should be able to come up with a minimal config for 'CONFIG_MACH_OMAP3_BEAGLE=y', and then a minimal config for whatever is in omap3_beagle_defconfig. The diff is either unnecessary, or the Kconfig files are missing some 'default y if whatever'. You fix Yes, that's why I lean toward the solution that creates an ideal config with the minimal effort: SAT with a single I don't really see the big need for hierarchical configs. When you do 'make ARCH=arm' you are already including all the arm stuff, so there's no need for an ARM base config. Then you would need some platform stuff like OMAP3, but if you do CONFIG_ARCH_OMAP3=y, and there are proper 'default y if ARCH_OMAP3' in the Kconfigs, you don't need any base config either. The rest of the stuff is truly specific to the boards. If there's a need to include other configs, I'm sure we can come with markups to include them and have a parser script that generates the Yes, although I don't like the format (it looks clearly designed for something else), it's another possibility. However, I don't think "allnoconfig" makes sense because that would ignore the default hints already present in Kconfig files. -- Felipe Contreras --
We could just alias commands so when the user runs "make ARCH=arm omap3_evm_defconfig" it would just do whatever this command does , "KBUILD_KCONFIG=arch/arm/configs/Kconfig.omap3_evm make allnoconfig" but those Kconfigs wouldn't be in "make menuconfig" it would just exist to generate the defconfigs, or the .config .. So Kconfig.omap3_evm basically becomes the defconfig. That doesn't seem un-reasonable. Although the solver to me seems more elegant and we're getting the solver for some other reasons it seems (unrelated to this defconfig issue). Daniel --
Seems to me that the brokenness of select is the main technical issue stopping us getting rid of the defconfigs. If there was a way to tell the Kconfig machinery "I want CONFIG_USB on, you figure out what has to be enabled for that to make sense" then it would all work. But that's a hard problem (and may possibly have multiple solutions). Paul. --
Yes, I think you're right. If select was 'smart', then the whole issue kind of goes away. But as you say, that is a hard problem. In the mean time, I'd be satisfied with a solution that punted out an error at configure time if select requirements did not get met. I should look at the patch Catalin posted. g. --
On Thu, Jun 3, 2010 at 11:31 PM, Linus Torvalds And that's precisely the problem that his approach doesn't solve: dependencies. --- config MYCONFIG bool default y select MACH_OMAP3_BEAGLE source arch/arm/Kconfig --- Is the same as: --- source arch/arm/Kconfig --- With the SAT resolver it would be possible to have a .satconfig: CONFIG_MACH_OMAP3_BEAGLE=y And let the resolver figure everything out back from there. -- Felipe Contreras --
Isn't that the point? If you have a specific platform, you don't want to pick them, you want to get the particular config file for it as a starting point. That's the _only_ reason to have those insane 177 defconfig files - because you want a _particular_ one. Once you have a particular one, you can always edit it with the regular configuration tools - including making tweaks by hand - as much as you want. So the only point of the thing would always be to get a result config file, one that you can then edit to your hearts content. And get it from a human-readable and writable description file, so that it would make sense to check it in to the kernel repository. Because right now, the current defconfig files DO NOT MAKE SENSE in the kernel repository. They are useless crud, and they hurt. So what I do _not_ want is the current crazy "give people these totally unreadable and unwritable raw config files". I want that extra step in between: something that allows you to _generate_ those idiotic files, but generate them from a reasonable human-editable template. And a Kconfig.xyz file _could_ be such a template. But anyway, I'm not actually all that excited about playing games with Kconfig files either. And I simply don't care. To me, a "git rm *defconfig" is perfectly acceptable. If you want to keep the current defconfig files, you can keep them on some random ARM site ("Here's a defconfig file for Nexus One"). So I'm actually perfectly fine with "no defconfig files at all, not even a template that can generate them". You can get the files from somewhere else where they don't hurt the kernel. Linus --
What do you define as useable? at two extremes: do you mean a kernel that fully supports the board and all it's features? do you mean a kernel that will compile and boot, but may not be able to talk to the outside world as it doesn't know about any I/O that the chip may have. I don't think that defconfig can work for the first case (every single system would hae it's own defconfig, which just doesn't scale) and I'm not sure the second is very useful (and it should be covered by the kconfig defaults) if you are looking for something in between, where do you draw the line? back when linux ran on x86 with IDE only, defconfig made a lot of sense, but that was because the hardware was very standardized, nowdays even in the x6 space there is enough variation that it's questionable how useful a defconfig is. What would be far better would be some tool that would take some hardware defintition (either autodetecting from a currenlty running system on x86, or from the device_tree stuff that's being worked on for other architectures) and create a kernel config from that that would fully support the hardware detected. --
