ARM defconfig files

ARM defconfig files

[Uwe Kleine-König]

Hello,

[Added linux-arm-kernel ML to Cc, note that it's moderated for
non-subscribers.]

On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 3 Jun 2010, Daniel Walker wrote:
> > 
> > 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.
> 
> 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).
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 HAVE_MTD_NAND_MXC
		help
		  ...

	...
	config MACH_MX27ADS
		...
		select HAVE_MTD_NAND_MXC

.  Compared with selecting everything in Kconfig files this approach
allows further tweaking of a config.  (E.g. "I have a mx27ads machine,
but I don't need nand support.")  Compared with the SAT-Solver it's an
idea that works today.

One downside of this approach (when done with my script only) is that
too much is removed.  E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed.
This is OK from a logical POV but then changing the default of the
corresponding choice (and I intend to do that in the near future) would
break this defconfig.

I can share my script and I'm willing to support maintaining the
minimality of the defconfig files if they are an acceptable (maybe
intermediate) step for Linus.

Together with the efforts to reduce the number of defconfigs as thought
about in other mails of this thread the situation should become quite
better for Linus.  (I'm currently working on merging support for all
Freescale SoCs into a single mach- directory and so merge mx1_defconfig,
mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and
mx51_defconfig.)

Linus: I would really appreciate if you wouldn't remove all (or nearly
all) defconfig files.  I think you would force a quicker solution to
this problem, but during that time the ARM community would loose compile
coverage.

Thoughts on this?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

ARM defconfig files

[Uwe Kleine-König]

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

On Mon, Jun 14, 2010 at 10:32:14AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> [Added linux-arm-kernel ML to Cc, note that it's moderated for
> non-subscribers.]
> 
> On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Thu, 3 Jun 2010, Daniel Walker wrote:
> > > 
> > > 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.
> > 
> > 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).
> 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 HAVE_MTD_NAND_MXC
> 		help
> 		  ...
> 
> 	...
> 	config MACH_MX27ADS
> 		...
> 		select HAVE_MTD_NAND_MXC
> 
> .  Compared with selecting everything in Kconfig files this approach
> allows further tweaking of a config.  (E.g. "I have a mx27ads machine,
> but I don't need nand support.")  Compared with the SAT-Solver it's an
> idea that works today.
> 
> One downside of this approach (when done with my script only) is that
> too much is removed.  E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed.
> This is OK from a logical POV but then changing the default of the
> corresponding choice (and I intend to do that in the near future) would
> break this defconfig.
> 
> I can share my script and I'm willing to support maintaining the
> minimality of the defconfig files if they are an acceptable (maybe
> intermediate) step for Linus.
> 
> Together with the efforts to reduce the number of defconfigs as thought
> about in other mails of this thread the situation should become quite
> better for Linus.  (I'm currently working on merging support for all
> Freescale SoCs into a single mach- directory and so merge mx1_defconfig,
> mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and
> mx51_defconfig.)
> 
> Linus: I would really appreciate if you wouldn't remove all (or nearly
> all) defconfig files.  I think you would force a quicker solution to
> this problem, but during that time the ARM community would loose compile
> coverage.
> 
> Thoughts on this?
> 
> Best regards
> Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

ARM defconfig files

[Uwe Kleine-König]

Hi Linus,

On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-K?nig wrote:
> 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?
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/  |

ARM defconfig files

[Linus Torvalds]

2010/7/12 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>
> 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.

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

ARM defconfig files

[Russell King - ARM Linux]

On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote:
> 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.

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.

ARM defconfig files

[Linus Torvalds]

On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> When you brought up the problem you seemed absolutely convinced
> that nothing except your solution was going to be acceptable.

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

ARM defconfig files

[Uwe Kleine-König]

Hello Linus,

On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > When you brought up the problem you seemed absolutely convinced
> > that nothing except your solution was going to be acceptable.
> 
> 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.
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             |  721 ---------
 arch/arm/configs/cam60_defconfig               | 1089 +-------------
 arch/arm/configs/carmeva_defconfig             |  696 +--------
 arch/arm/configs/cerfcube_defconfig            |  851 +----------
 arch/arm/configs/cm_t35_defconfig              | 1577 +------------------
 arch/arm/configs/cm_x2xx_defconfig             | 1774 +---------------------
 arch/arm/configs/cm_x300_defconfig             | 1565 ------------------
 arch/arm/configs/cns3420vb_defconfig           |  759 ---------
 arch/arm/configs/colibri_pxa270_defconfig      | 1556 ------------------
 arch/arm/configs/colibri_pxa300_defconfig      | 1082 -------------
 arch/arm/configs/collie_defconfig              |  887 +----------
 arch/arm/configs/corgi_defconfig               | 1621 +-------------------
 arch/arm/configs/cpu9260_defconfig             | 1225 +--------------
 arch/arm/configs/cpu9g20_defconfig             | 1215 +--------------
 arch/arm/configs/cpuat91_defconfig             | 1207 +--------------
 arch/arm/configs/csb337_defconfig              | 1113 +-------------
 arch/arm/configs/csb637_defconfig              | 1124 +-------------
 arch/arm/configs/da8xx_omapl_defconfig         | 1205 --------------
 arch/arm/configs/davinci_all_defconfig         | 1641 -------------------
 arch/arm/configs/devkit8000_defconfig          | 1732 +--------------------
 arch/arm/configs/dove_defconfig                | 1482 -----------------
 arch/arm/configs/ebsa110_defconfig             |  692 +--------
 arch/arm/configs/ecbat91_defconfig             | 1226 +--------------
 arch/arm/configs/edb7211_defconfig             |  554 +-------
 arch/arm/configs/em_x270_defconfig             | 1554 +------------------
 arch/arm/configs/ep93xx_defconfig              | 1340 ----------------
 arch/arm/configs/eseries_pxa_defconfig         | 1128 -------------
 arch/arm/configs/ezx_defconfig                 | 1582 +-------------------
 arch/arm/configs/footbridge_defconfig          | 1185 +--------------
 arch/arm/configs/fortunet_defconfig            |  538 +-------
 arch/arm/configs/g3evm_defconfig               |  717 ---------
 arch/arm/configs/g4evm_defconfig               |  722 ---------
 arch/arm/configs/h3600_defconfig               | 1084 -------------
 arch/arm/configs/h5000_defconfig               |  917 +-----------
 arch/arm/configs/h7201_defconfig               |  542 +-------
 arch/arm/configs/h7202_defconfig               |  697 +--------
 arch/arm/configs/hackkit_defconfig             |  735 +---------
 arch/arm/configs/htcherald_defconfig           | 1073 +-------------
 arch/arm/configs/igep0020_defconfig            | 1467 -----------------
 arch/arm/configs/imote2_defconfig              | 1649 +-------------------
 arch/arm/configs/integrator_defconfig          |  817 +----------
 arch/arm/configs/iop13xx_defconfig             | 1061 +------------
 arch/arm/configs/iop32x_defconfig              | 1282 +---------------
 arch/arm/configs/iop33x_defconfig              | 1300 ---------------
 arch/arm/configs/ixp2000_defconfig             | 1024 +------------
 arch/arm/configs/ixp23xx_defconfig             | 1315 +---------------
 arch/arm/configs/ixp4xx_defconfig              | 1394 +----------------
 arch/arm/configs/jornada720_defconfig          | 1062 -------------
 arch/arm/configs/kafa_defconfig                |  830 +----------
 arch/arm/configs/kb9202_defconfig              | 1179 +--------------
 arch/arm/configs/kirkwood_defconfig            | 1700 --------------------
 arch/arm/configs/ks8695_defconfig              |  946 -----------
 arch/arm/configs/lart_defconfig                |  824 +----------
 arch/arm/configs/loki_defconfig                | 1028 +------------
 arch/arm/configs/lpd270_defconfig              |  968 +------------
 arch/arm/configs/lpd7a400_defconfig            |  835 +----------
 arch/arm/configs/lpd7a404_defconfig            | 1050 +------------
 arch/arm/configs/lubbock_defconfig             |  762 +---------
 arch/arm/configs/lusl7200_defconfig            |  436 +-----
 arch/arm/configs/magician_defconfig            | 1358 +----------------
 arch/arm/configs/mainstone_defconfig           |  755 +---------
 arch/arm/configs/mini2440_defconfig            | 1722 +--------------------
 arch/arm/configs/mmp2_defconfig                | 1135 -------------
 arch/arm/configs/msm_defconfig                 |  830 +----------
 arch/arm/configs/mv78xx0_defconfig             | 1547 ------------------
 arch/arm/configs/mx1_defconfig                 | 1018 +------------
 arch/arm/configs/mx21_defconfig                | 1072 -------------
 arch/arm/configs/mx27_defconfig                | 1152 --------------
 arch/arm/configs/mx31pdk_defconfig             |  728 ---------
 arch/arm/configs/mx3_defconfig                 | 1089 -------------
 arch/arm/configs/mx51_defconfig                | 1130 -------------
 arch/arm/configs/n770_defconfig                | 1283 ---------------
 arch/arm/configs/n8x0_defconfig                | 1134 +-------------
 arch/arm/configs/neocore926_defconfig          | 1205 +--------------
 arch/arm/configs/neponset_defconfig            | 1081 +-------------
 arch/arm/configs/netwinder_defconfig           |  978 +------------
 arch/arm/configs/netx_defconfig                |  845 +----------
 arch/arm/configs/nhk8815_defconfig             | 1185 +--------------
 arch/arm/configs/ns9xxx_defconfig              |   23 -
 arch/arm/configs/nuc910_defconfig              |  844 ----------
 arch/arm/configs/nuc950_defconfig              |  896 -----------
 arch/arm/configs/nuc960_defconfig              |  855 ----------
 arch/arm/configs/omap3_beagle_defconfig        | 1258 +---------------
 arch/arm/configs/omap3_defconfig               | 1969 -----------------------
 arch/arm/configs/omap3_evm_defconfig           | 1429 +-----------------
 arch/arm/configs/omap3_pandora_defconfig       | 1640 +-------------------
 arch/arm/configs/omap3_stalker_lks_defconfig   | 1541 ------------------
 arch/arm/configs/omap3_touchbook_defconfig     | 1809 ---------------------
 arch/arm/configs/omap_2430sdp_defconfig        | 1181 +--------------
 arch/arm/configs/omap_3430sdp_defconfig        | 1553 +------------------
 arch/arm/configs/omap_3630sdp_defconfig        | 1456 -----------------
 arch/arm/configs/omap_4430sdp_defconfig        | 1157 --------------
 arch/arm/configs/omap_apollon_2420_defconfig   |  873 +----------
 arch/arm/configs/omap_generic_1510_defconfig   | 1089 +-------------
 arch/arm/configs/omap_generic_1610_defconfig   | 1092 +-------------
 arch/arm/configs/omap_generic_1710_defconfig   | 1014 +------------
 arch/arm/configs/omap_generic_2420_defconfig   |  619 +--------
 arch/arm/configs/omap_h2_1610_defconfig        | 1234 +---------------
 arch/arm/configs/omap_h4_2420_defconfig        | 1018 +------------
 arch/arm/configs/omap_innovator_1510_defconfig | 1152 +--------------
 arch/arm/configs/omap_innovator_1610_defconfig |  780 ---------
 arch/arm/configs/omap_ldp_defconfig            | 1124 -------------
 arch/arm/configs/omap_osk_5912_defconfig       | 1003 ------------
 arch/arm/configs/omap_perseus2_730_defconfig   |  862 ----------
 arch/arm/configs/omap_zoom2_defconfig          | 1408 +-----------------
 arch/arm/configs/omap_zoom3_defconfig          | 1455 -----------------
 arch/arm/configs/onearm_defconfig              | 1067 +-------------
 arch/arm/configs/orion5x_defconfig             | 1693 --------------------
 arch/arm/configs/overo_defconfig               | 1621 +-------------------
 arch/arm/configs/palmte_defconfig              |  712 ---------
 arch/arm/configs/palmtt_defconfig              |  801 +----------
 arch/arm/configs/palmz71_defconfig             |  839 +----------
 arch/arm/configs/palmz72_defconfig             |  865 ----------
 arch/arm/configs/pcm027_defconfig              |  993 ------------
 arch/arm/configs/picotux200_defconfig          | 1207 +--------------
 arch/arm/configs/pleb_defconfig                |  712 +--------
 arch/arm/configs/pnx4008_defconfig             | 1286 +---------------
 arch/arm/configs/pxa168_defconfig              |  903 -----------
 arch/arm/configs/pxa255-idp_defconfig          |  753 +---------
 arch/arm/configs/pxa3xx_defconfig              | 1207 +--------------
 arch/arm/configs/pxa910_defconfig              |  820 ----------
 arch/arm/configs/qil-a9260_defconfig           | 1146 +--------------
 arch/arm/configs/raumfeld_defconfig            | 1690 --------------------
 arch/arm/configs/realview-smp_defconfig        | 1005 ------------
 arch/arm/configs/realview_defconfig            | 1001 ------------
 arch/arm/configs/rpc_defconfig                 |  882 +-----------
 arch/arm/configs/rx51_defconfig                | 1648 +-------------------
 arch/arm/configs/s3c2410_defconfig             | 2018 ------------------------
 arch/arm/configs/s3c6400_defconfig             | 1445 -----------------
 arch/arm/configs/s5p6440_defconfig             |  947 -----------
 arch/arm/configs/s5p6442_defconfig             |  842 ----------
 arch/arm/configs/s5pc100_defconfig             |  977 ------------
 arch/arm/configs/s5pc110_defconfig             |  858 ----------
 arch/arm/configs/s5pv210_defconfig             |  861 ----------
 arch/arm/configs/sam9_l9260_defconfig          |  962 +-----------
 arch/arm/configs/shannon_defconfig             |  837 +----------
 arch/arm/configs/shark_defconfig               | 1167 --------------
 arch/arm/configs/simpad_defconfig              |  886 +----------
 arch/arm/configs/spear300_defconfig            |  722 ---------
 arch/arm/configs/spear310_defconfig            |  723 ---------
 arch/arm/configs/spear320_defconfig            |  723 ---------
 arch/arm/configs/spear600_defconfig            |  711 ---------
 arch/arm/configs/spitz_defconfig               | 1547 +------------------
 arch/arm/configs/stamp9g20_defconfig           | 1327 ----------------
 arch/arm/configs/stmp378x_defconfig            | 1014 +------------
 arch/arm/configs/stmp37xx_defconfig            |  895 +-----------
 arch/arm/configs/sx1_defconfig                 | 1015 +------------
 arch/arm/configs/tct_hammer_defconfig          |  817 +----------
 arch/arm/configs/trizeps4_defconfig            | 1502 +-----------------
 arch/arm/configs/u300_defconfig                | 1118 -------------
 arch/arm/configs/u8500_defconfig               |  621 --------
 arch/arm/configs/usb-a9260_defconfig           | 1039 +------------
 arch/arm/configs/usb-a9263_defconfig           | 1031 +------------
 arch/arm/configs/versatile_defconfig           |  928 +-----------
 arch/arm/configs/viper_defconfig               | 1502 ------------------
 arch/arm/configs/xcep_defconfig                | 1031 +------------
 arch/arm/configs/yl9200_defconfig              | 1084 +-------------
 arch/arm/configs/zeus_defconfig                | 1842 ---------------------
 177 files changed, 652 insertions(+), 194157 deletions(-)

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

ARM defconfig files

[Linus Torvalds]

2010/7/12 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>
> 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.

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
very powerful thing:

>  177 files changed, 652 insertions(+), 194157 deletions(-)

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

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Linus Torvalds wrote:

> I'd happily pull it. Just this single line in your email is a very
> very powerful thing:
> 
> >  177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> 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.

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 
issue should be noticed right away.

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

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

ARM defconfig files

[Linus Torvalds]

On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>>
>> ? ?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.
>
> 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
> issue should be noticed right away.

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
though I do see advantages.

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

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

ARM defconfig files

[Grant Likely]

On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> 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.
>
> 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 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.

ARM defconfig files

[Uwe Kleine-König]

Hi

On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >> 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.
> >
> > 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 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.
I just restarted my script on the powerpc defconfigs basing on rc5, I
assume they complete in a few days time.
 
> Of course, I'm also operating under the assumption that this is a
> temporary measure until one of the better solutions is implemented.
ack

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

optimized script [Was: ARM defconfig files]

[Uwe Kleine-König]

Hello,

On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> Hi
> 
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > >> 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.
> > >
> > > 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 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.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
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/  |
-------------- next part --------------
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

import getopt
import re
import os
import subprocess
import sys

# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'

re_interesting = re.compile(r'^(# )?CONFIG_')

opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src='])

src = ''
arch = 'arm'

for o, a in opts:
    if o == '--arch':
        arch = a
    elif o == '--src':
        src = a

configdir = os.path.join(src, 'arch', arch, 'configs')

def all_defconfigs():
    lc = len(configdir)
    for root, dirs, files in os.walk(configdir):
        root = root[lc + 1:]
        for f in filter(lambda s: s.endswith('_defconfig'), files):
            yield os.path.join(root, f)

if not args:
    args = all_defconfigs()

for target in args:
    defconfig_src = os.path.join(configdir, target)

    subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
    origconfig = list(open('.config'))
    config = list(origconfig)
    config_size = os.stat('.config').st_size

    i = 0

    while i < len(config):
        mo = re_interesting.match(config[i])
        if mo:
            defconfig = open(defconfig_src, 'w')
            defconfig.writelines(config[:i])
            defconfig.writelines(config[i + 1:])
            defconfig.close()
            subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
            if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
                print '-%s' % config[i][:-1]
                del config[i]
            else:
                print ' %s' % config[i][:-1]
                i += 1
        else:
            del config[i]

    defconfig = open(defconfig_src, 'w')
    defconfig.writelines(config)
    defconfig.close()

optimized script [Was: ARM defconfig files]

[Olof Johansson]

On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> > Hi
> > 
> > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > >> 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.
> > > >
> > > > 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 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.
> > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > assume they complete in a few days time.
> 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).

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

optimized script [Was: ARM defconfig files]

[Nicolas Pitre]

On Tue, 13 Jul 2010, Olof Johansson wrote:

> On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> > > Hi
> > > 
> > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > > >> 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.
> > > > >
> > > > > 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 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.
> > > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > > assume they complete in a few days time.
> > 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).
> 
> 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).
> 
[...]
> 
> 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.

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

ARM defconfig files

[Grant Likely]

2010/7/13 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
>> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> >> 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.
>> >
>> > 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 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.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
>
>> Of course, I'm also operating under the assumption that this is a
>> temporary measure until one of the better solutions is implemented.
> ack
>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?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.
> 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.

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
defaults.  So either way, defconfigs are simply a broken concept.

> And ack, I like the Kconfig approach, too.

Yeah, the problem goes away with Kconfig fragments.  A programmer can
then explicitly state which CONFIG values need to be overridden.

g.

ARM defconfig files

[Uwe Kleine-König]

Hi Linus,

On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >>
> >> ? ?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.
> >
> > 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
> > issue should be noticed right away.
> 
> 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.
I hoped you to pull this in during the merge window, but doing it now is
OK for me, too.
 
> 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?
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
that it's public you can convince yourself it's (hopefully) correct.
 
> 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?
No, $(make ..._defconfig) is enough to get the full .config.

>               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.
Right.

> 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
> though I do see advantages.
> 
> > 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.
> 
> 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
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/  |
-------------- next part --------------
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

import re
import subprocess
import os
import sys

# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'

# XXX: get these using getopt
kernel_tree = '' # os.path.join(os.environ['HOME'], 'gsrc', 'linux-2.6')
arch = 'arm'
target = sys.argv[1]
defconfig_src = os.path.join(kernel_tree, 'arch/%s/configs/%s' % (arch, target))

subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
origconfig = list(open('.config'))
config = list(origconfig)
config_size = os.stat('.config').st_size

i = 0

while i < len(config):
    print 'test for %r' % config[i]
    defconfig = open(defconfig_src, 'w')
    defconfig.writelines(config[:i])
    defconfig.writelines(config[i + 1:])
    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]
    else:
        i += 1

defconfig = open(defconfig_src, 'w')
defconfig.writelines(config)
defconfig.close()

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Linus Torvalds wrote:

> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >>
> >> ? ?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.
> >
> > 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
> > issue should be noticed right away.
> 
> 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).

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 
configurations not final product ones.

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

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.  
During the merge window this would create even more headaches.

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

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 
this makes it pretty safe to me.

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

I'll let Uwe answer this.

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

That is going to be the case regardless of the merge timing for this.

> 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
> though I do see advantages.

I do too.  At least this is positive progress for some bad issue that no 
one could ever get very passionate about.  Better keep the momentum.

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

Pretty easy to see on the diffstat graph.  Anyway, I'm sure once the 
script is available then an army of kernel janitors will be busy trying 
to find any transgressor.

> 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

I'm sure the script was quickly cobbled together as a proof of concept.  
But once this defconfig reduction goes in then interest for a solid 
script should raise significantly.



Nicolas

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Uwe Kleine-K?nig wrote:
> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> > 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.

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, 
while giving us a better footing to develop a final solution.

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

ACK.

> 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             |  721 ---------
>  arch/arm/configs/cam60_defconfig               | 1089 +-------------
>  arch/arm/configs/carmeva_defconfig             |  696 +--------
>  arch/arm/configs/cerfcube_defconfig            |  851 +----------
>  arch/arm/configs/cm_t35_defconfig              | 1577 +------------------
>  arch/arm/configs/cm_x2xx_defconfig             | 1774 +---------------------
>  arch/arm/configs/cm_x300_defconfig             | 1565 ------------------
>  arch/arm/configs/cns3420vb_defconfig           |  759 ---------
>  arch/arm/configs/colibri_pxa270_defconfig      | 1556 ------------------
>  arch/arm/configs/colibri_pxa300_defconfig      | 1082 -------------
>  arch/arm/configs/collie_defconfig              |  887 +----------
>  arch/arm/configs/corgi_defconfig               | 1621 +-------------------
>  arch/arm/configs/cpu9260_defconfig             | 1225 +--------------
>  arch/arm/configs/cpu9g20_defconfig             | 1215 +--------------
>  arch/arm/configs/cpuat91_defconfig             | 1207 +--------------
>  arch/arm/configs/csb337_defconfig              | 1113 +-------------
>  arch/arm/configs/csb637_defconfig              | 1124 +-------------
>  arch/arm/configs/da8xx_omapl_defconfig         | 1205 --------------
>  arch/arm/configs/davinci_all_defconfig         | 1641 -------------------
>  arch/arm/configs/devkit8000_defconfig          | 1732 +--------------------
>  arch/arm/configs/dove_defconfig                | 1482 -----------------
>  arch/arm/configs/ebsa110_defconfig             |  692 +--------
>  arch/arm/configs/ecbat91_defconfig             | 1226 +--------------
>  arch/arm/configs/edb7211_defconfig             |  554 +-------
>  arch/arm/configs/em_x270_defconfig             | 1554 +------------------
>  arch/arm/configs/ep93xx_defconfig              | 1340 ----------------
>  arch/arm/configs/eseries_pxa_defconfig         | 1128 -------------
>  arch/arm/configs/ezx_defconfig                 | 1582 +-------------------
>  arch/arm/configs/footbridge_defconfig          | 1185 +--------------
>  arch/arm/configs/fortunet_defconfig            |  538 +-------
>  arch/arm/configs/g3evm_defconfig               |  717 ---------
>  arch/arm/configs/g4evm_defconfig               |  722 ---------
>  arch/arm/configs/h3600_defconfig               | 1084 -------------
>  arch/arm/configs/h5000_defconfig               |  917 +-----------
>  arch/arm/configs/h7201_defconfig               |  542 +-------
>  arch/arm/configs/h7202_defconfig               |  697 +--------
>  arch/arm/configs/hackkit_defconfig             |  735 +---------
>  arch/arm/configs/htcherald_defconfig           | 1073 +-------------
>  arch/arm/configs/igep0020_defconfig            | 1467 -----------------
>  arch/arm/configs/imote2_defconfig              | 1649 +-------------------
>  arch/arm/configs/integrator_defconfig          |  817 +----------
>  arch/arm/configs/iop13xx_defconfig             | 1061 +------------
>  arch/arm/configs/iop32x_defconfig              | 1282 +---------------
>  arch/arm/configs/iop33x_defconfig              | 1300 ---------------
>  arch/arm/configs/ixp2000_defconfig             | 1024 +------------
>  arch/arm/configs/ixp23xx_defconfig             | 1315 +---------------
>  arch/arm/configs/ixp4xx_defconfig              | 1394 +----------------
>  arch/arm/configs/jornada720_defconfig          | 1062 -------------
>  arch/arm/configs/kafa_defconfig                |  830 +----------
>  arch/arm/configs/kb9202_defconfig              | 1179 +--------------
>  arch/arm/configs/kirkwood_defconfig            | 1700 --------------------
>  arch/arm/configs/ks8695_defconfig              |  946 -----------
>  arch/arm/configs/lart_defconfig                |  824 +----------
>  arch/arm/configs/loki_defconfig                | 1028 +------------
>  arch/arm/configs/lpd270_defconfig              |  968 +------------
>  arch/arm/configs/lpd7a400_defconfig            |  835 +----------
>  arch/arm/configs/lpd7a404_defconfig            | 1050 +------------
>  arch/arm/configs/lubbock_defconfig             |  762 +---------
>  arch/arm/configs/lusl7200_defconfig            |  436 +-----
>  arch/arm/configs/magician_defconfig            | 1358 +----------------
>  arch/arm/configs/mainstone_defconfig           |  755 +---------
>  arch/arm/configs/mini2440_defconfig            | 1722 +--------------------
>  arch/arm/configs/mmp2_defconfig                | 1135 -------------
>  arch/arm/configs/msm_defconfig                 |  830 +----------
>  arch/arm/configs/mv78xx0_defconfig             | 1547 ------------------
>  arch/arm/configs/mx1_defconfig                 | 1018 +------------
>  arch/arm/configs/mx21_defconfig                | 1072 -------------
>  arch/arm/configs/mx27_defconfig                | 1152 --------------
>  arch/arm/configs/mx31pdk_defconfig             |  728 ---------
>  arch/arm/configs/mx3_defconfig                 | 1089 -------------
>  arch/arm/configs/mx51_defconfig                | 1130 -------------
>  arch/arm/configs/n770_defconfig                | 1283 ---------------
>  arch/arm/configs/n8x0_defconfig                | 1134 +-------------
>  arch/arm/configs/neocore926_defconfig          | 1205 +--------------
>  arch/arm/configs/neponset_defconfig            | 1081 +-------------
>  arch/arm/configs/netwinder_defconfig           |  978 +------------
>  arch/arm/configs/netx_defconfig                |  845 +----------
>  arch/arm/configs/nhk8815_defconfig             | 1185 +--------------
>  arch/arm/configs/ns9xxx_defconfig              |   23 -
>  arch/arm/configs/nuc910_defconfig              |  844 ----------
>  arch/arm/configs/nuc950_defconfig              |  896 -----------
>  arch/arm/configs/nuc960_defconfig              |  855 ----------
>  arch/arm/configs/omap3_beagle_defconfig        | 1258 +---------------
>  arch/arm/configs/omap3_defconfig               | 1969 -----------------------
>  arch/arm/configs/omap3_evm_defconfig           | 1429 +-----------------
>  arch/arm/configs/omap3_pandora_defconfig       | 1640 +-------------------
>  arch/arm/configs/omap3_stalker_lks_defconfig   | 1541 ------------------
>  arch/arm/configs/omap3_touchbook_defconfig     | 1809 ---------------------
>  arch/arm/configs/omap_2430sdp_defconfig        | 1181 +--------------
>  arch/arm/configs/omap_3430sdp_defconfig        | 1553 +------------------
>  arch/arm/configs/omap_3630sdp_defconfig        | 1456 -----------------
>  arch/arm/configs/omap_4430sdp_defconfig        | 1157 --------------
>  arch/arm/configs/omap_apollon_2420_defconfig   |  873 +----------
>  arch/arm/configs/omap_generic_1510_defconfig   | 1089 +-------------
>  arch/arm/configs/omap_generic_1610_defconfig   | 1092 +-------------
>  arch/arm/configs/omap_generic_1710_defconfig   | 1014 +------------
>  arch/arm/configs/omap_generic_2420_defconfig   |  619 +--------
>  arch/arm/configs/omap_h2_1610_defconfig        | 1234 +---------------
>  arch/arm/configs/omap_h4_2420_defconfig        | 1018 +------------
>  arch/arm/configs/omap_innovator_1510_defconfig | 1152 +--------------
>  arch/arm/configs/omap_innovator_1610_defconfig |  780 ---------
>  arch/arm/configs/omap_ldp_defconfig            | 1124 -------------
>  arch/arm/configs/omap_osk_5912_defconfig       | 1003 ------------
>  arch/arm/configs/omap_perseus2_730_defconfig   |  862 ----------
>  arch/arm/configs/omap_zoom2_defconfig          | 1408 +-----------------
>  arch/arm/configs/omap_zoom3_defconfig          | 1455 -----------------
>  arch/arm/configs/onearm_defconfig              | 1067 +-------------
>  arch/arm/configs/orion5x_defconfig             | 1693 --------------------
>  arch/arm/configs/overo_defconfig               | 1621 +-------------------
>  arch/arm/configs/palmte_defconfig              |  712 ---------
>  arch/arm/configs/palmtt_defconfig              |  801 +----------
>  arch/arm/configs/palmz71_defconfig             |  839 +----------
>  arch/arm/configs/palmz72_defconfig             |  865 ----------
>  arch/arm/configs/pcm027_defconfig              |  993 ------------
>  arch/arm/configs/picotux200_defconfig          | 1207 +--------------
>  arch/arm/configs/pleb_defconfig                |  712 +--------
>  arch/arm/configs/pnx4008_defconfig             | 1286 +---------------
>  arch/arm/configs/pxa168_defconfig              |  903 -----------
>  arch/arm/configs/pxa255-idp_defconfig          |  753 +---------
>  arch/arm/configs/pxa3xx_defconfig              | 1207 +--------------
>  arch/arm/configs/pxa910_defconfig              |  820 ----------
>  arch/arm/configs/qil-a9260_defconfig           | 1146 +--------------
>  arch/arm/configs/raumfeld_defconfig            | 1690 --------------------
>  arch/arm/configs/realview-smp_defconfig        | 1005 ------------
>  arch/arm/configs/realview_defconfig            | 1001 ------------
>  arch/arm/configs/rpc_defconfig                 |  882 +-----------
>  arch/arm/configs/rx51_defconfig                | 1648 +-------------------
>  arch/arm/configs/s3c2410_defconfig             | 2018 ------------------------
>  arch/arm/configs/s3c6400_defconfig             | 1445 -----------------
>  arch/arm/configs/s5p6440_defconfig             |  947 -----------
>  arch/arm/configs/s5p6442_defconfig             |  842 ----------
>  arch/arm/configs/s5pc100_defconfig             |  977 ------------
>  arch/arm/configs/s5pc110_defconfig             |  858 ----------
>  arch/arm/configs/s5pv210_defconfig             |  861 ----------
>  arch/arm/configs/sam9_l9260_defconfig          |  962 +-----------
>  arch/arm/configs/shannon_defconfig             |  837 +----------
>  arch/arm/configs/shark_defconfig               | 1167 --------------
>  arch/arm/configs/simpad_defconfig              |  886 +----------
>  arch/arm/configs/spear300_defconfig            |  722 ---------
>  arch/arm/configs/spear310_defconfig            |  723 ---------
>  arch/arm/configs/spear320_defconfig            |  723 ---------
>  arch/arm/configs/spear600_defconfig            |  711 ---------
>  arch/arm/configs/spitz_defconfig               | 1547 +------------------
>  arch/arm/configs/stamp9g20_defconfig           | 1327 ----------------
>  arch/arm/configs/stmp378x_defconfig            | 1014 +------------
>  arch/arm/configs/stmp37xx_defconfig            |  895 +-----------
>  arch/arm/configs/sx1_defconfig                 | 1015 +------------
>  arch/arm/configs/tct_hammer_defconfig          |  817 +----------
>  arch/arm/configs/trizeps4_defconfig            | 1502 +-----------------
>  arch/arm/configs/u300_defconfig                | 1118 -------------
>  arch/arm/configs/u8500_defconfig               |  621 --------
>  arch/arm/configs/usb-a9260_defconfig           | 1039 +------------
>  arch/arm/configs/usb-a9263_defconfig           | 1031 +------------
>  arch/arm/configs/versatile_defconfig           |  928 +-----------
>  arch/arm/configs/viper_defconfig               | 1502 ------------------
>  arch/arm/configs/xcep_defconfig                | 1031 +------------
>  arch/arm/configs/yl9200_defconfig              | 1084 +-------------
>  arch/arm/configs/zeus_defconfig                | 1842 ---------------------
>  177 files changed, 652 insertions(+), 194157 deletions(-)
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 

ARM defconfig files

[Arnd Bergmann]

On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote:
> 
> [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

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

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Arnd Bergmann wrote:

> On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote:
> > 
> > [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
> 
> 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:

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

ARM defconfig files

[David Brown]

On Monday 12 July 2010 11:50:29 Uwe Kleine-K?nig wrote:

> If it helps the powerpc people I can reduce their defconfigs, too.

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

ARM defconfig files

[Linus Torvalds]

2010/7/12 David Brown <davidb@codeaurora.org>:
>
> 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.

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

ARM defconfig files

[David Brown]

On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:

> 2010/7/12 David Brown <davidb@codeaurora.org>:
> >
> > 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.
> 
> 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.

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

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, David Brown wrote:

> On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
> 
> > 2010/7/12 David Brown <davidb@codeaurora.org>:
> > >
> > > 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.
> > 
> > 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.
> 
> 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.

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

ARM defconfig files

[Felipe Contreras]

On Tue, Jul 13, 2010 at 2:34 AM, David Brown <davidb@codeaurora.org> wrote:
> 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.

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

ARM defconfig files

[Uwe Kleine-König]

On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote:
> On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
> 
> > 2010/7/12 David Brown <davidb@codeaurora.org>:
> > >
> > > 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.
> > 
> > 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.
> 
> 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.
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/  |

ARM defconfig files

[Tony Luck]

2010/7/14 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Note that no kernel is built at all, only the config is regenerated once
> for each line.

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

ARM defconfig files

[Rob Landley]

On Monday 12 July 2010 18:18:01 Linus Torvalds wrote:
> 2010/7/12 David Brown <davidb@codeaurora.org>:
> > 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.
>
> 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.

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 append:

CONFIG_MIPS_MALTA=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
#CONFIG_PM=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y

Or for x86_64 it's:

CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

And for armv4tl it's this big long saga (yes, with comments):

# Processor config

# QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html
# and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the
# processor that actually _needs_ this code.  But until then, qemu can only
# emulate an armv5 CPU...

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_VFP=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

Rob
-- 
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
-------------- next part --------------
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

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_ARCH_VERSATILE_PB=y
CONFIG_MACH_VERSATILE_AB=y
CONFIG_CPU_ARM926T=y
CONFIG_ARM_THUMB=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y

-------------- next part --------------
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


# Processor config

# QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html
# and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the
# processor that actually _needs_ this code.  But until then, qemu can only
# emulate an armv5 CPU...

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

-------------- next part --------------
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


# Processor config

# QEMU patch: http://www.mail-archive.com/qemu-devel at nongnu.org/msg19370.html
# and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the
# processor that actually _needs_ this code.  But until then, qemu can only
# emulate an armv5 CPU...

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_VFP=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

-------------- next part --------------
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


# Processor config

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_VFP=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

-------------- next part --------------
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


# Processor config

CONFIG_CPU_V6=y
CONFIG_MMU=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y
CONFIG_VFP=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

-------------- next part --------------
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

CONFIG_M486=y
CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

-------------- next part --------------
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

CONFIG_M586=y
CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

-------------- next part --------------
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

CONFIG_MPENTIUMII=y
CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

-------------- next part --------------
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

CONFIG_MIPS_MALTA=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
#CONFIG_PM=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y

-------------- next part --------------
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

CONFIG_CPU_MIPS64_R1=y
CONFIG_64BIT=y
CONFIG_MIPS_MALTA=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y

-------------- next part --------------
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

CONFIG_MIPS_MALTA=y
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y

-------------- next part --------------
CONFIG_ALTIVEC=y
CONFIG_EXPERIMENTAL=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
CONFIG_LBDAF=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
CONFIG_PPC601_SYNC_FIX=y
CONFIG_HIGHMEM=y
CONFIG_NO_HZ=y
CONFIG_BINFMT_ELF=y
CONFIG_PROC_DEVICETREE=y
CONFIG_PM=y
CONFIG_SECCOMP=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_YENTA=y
CONFIG_ADVANCED_OPTIONS=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_INET_LRO=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=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_IDE_PROC_FS=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_ETH1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_IEEE1394_VIDEO1394=y
CONFIG_IEEE1394_DV1394=y
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MACE=y
CONFIG_BMAC=y
CONFIG_HAPPYMEAL=y
CONFIG_SUNGEM=y
CONFIG_CASSINI=y
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
CONFIG_NE2K_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_SERIO=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_SSB=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_PCMCIAHOST=y
CONFIG_SSB_DRIVER_PCICORE=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_PROC_KCORE=y
CONFIG_TMPFS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_LIBCRC32C=y
CONFIG_BOOTX_TEXT=y
CONFIG_CRYPTO_HW=y
-------------- next part --------------
CONFIG_ALTIVEC=y
CONFIG_EXPERIMENTAL=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
CONFIG_LBDAF=y
CONFIG_PPC_PMAC=y
CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
CONFIG_PPC601_SYNC_FIX=y
CONFIG_HIGHMEM=y
CONFIG_NO_HZ=y
CONFIG_BINFMT_ELF=y
CONFIG_PROC_DEVICETREE=y
CONFIG_PM=y
CONFIG_SECCOMP=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_YENTA=y
CONFIG_ADVANCED_OPTIONS=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_INET_LRO=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=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_IDE_PROC_FS=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_IEEE1394=y
CONFIG_IEEE1394_OHCI1394=y
CONFIG_IEEE1394_ETH1394=y
CONFIG_IEEE1394_RAWIO=y
CONFIG_IEEE1394_VIDEO1394=y
CONFIG_IEEE1394_DV1394=y
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_MACE=y
CONFIG_BMAC=y
CONFIG_HAPPYMEAL=y
CONFIG_SUNGEM=y
CONFIG_CASSINI=y
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
CONFIG_NE2K_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
CONFIG_SERIO=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_SSB=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_PCMCIAHOST=y
CONFIG_SSB_DRIVER_PCICORE=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_PROC_KCORE=y
CONFIG_TMPFS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_LIBCRC32C=y
CONFIG_BOOTX_TEXT=y
CONFIG_CRYPTO_HW=y
-------------- next part --------------
CONFIG_EXPERIMENTAL=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
CONFIG_CPU_SUBTYPE_SH7751R=y
CONFIG_MMU=y
CONFIG_MEMORY_START=0x0c000000
CONFIG_VSYSCALL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_SH_FPU=y
CONFIG_SH_RTS7751R2D=y
CONFIG_RTS7751R2D_PLUS=y
CONFIG_SH_TIMER_TMU=y
CONFIG_NO_HZ=y
CONFIG_HEARTBEAT=y
CONFIG_PCI=y
CONFIG_SH_PCIDMA_NONCOHERENT=y
CONFIG_PCI_LEGACY=y
CONFIG_HOTPLUG_PCI=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_RAM=y
CONFIG_MISC_DEVICES=y
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ATA=y
CONFIG_SATA_PMP=y
CONFIG_ATA_SFF=y
CONFIG_PATA_PLATFORM=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=1
CONFIG_SERIAL_SH_SCI_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_HW_RANDOM=y
CONFIG_SPI=y
CONFIG_SPI_SH_SCI=y
CONFIG_HWMON=y
CONFIG_MFD_SM501=y
CONFIG_FB=y
CONFIG_FB_SM501=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_LOGO=y
CONFIG_LOGO_SUPERH_CLUT224=y
CONFIG_SOUND=y
CONFIG_HID_SUPPORT=y
CONFIG_USB_HID=y
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_EZKEY=y
CONFIG_HID_GYRATION=y
CONFIG_HID_LOGITECH=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_PANTHERLORD=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_LIBUSUAL=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_R9701=y
CONFIG_EXT2_FS=y
CONFIG_FILE_LOCKING=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_MINIX_FS=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NLS_CODEPAGE_932=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_EARLY_SCIF_CONSOLE=y
CONFIG_EARLY_PRINTK=y
CONFIG_CRYPTO_HW=y
CONFIG_CRC_T10DIF=y
-------------- next part --------------
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

CONFIG_SCSI_SUNESP=y
CONFIG_SUNLANCE=y
CONFIG_SERIAL_SUNZILOG=y
CONFIG_SERIAL_SUNZILOG_CONSOLE=y
CONFIG_SUN_MOSTEK_RTC=y

-------------- next part --------------
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

CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

ARM defconfig files

[Russell King - ARM Linux]

On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > When you brought up the problem you seemed absolutely convinced
> > that nothing except your solution was going to be acceptable.
> 
> 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.

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.

ARM defconfig files

[Nicolas Pitre]

On Mon, 12 Jul 2010, Russell King - ARM Linux wrote:

> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > >
> > > When you brought up the problem you seemed absolutely convinced
> > > that nothing except your solution was going to be acceptable.
> > 
> > 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.
> 
> 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.

OK, please let's put this appearance of misunderstanding behind.  
The rehashing of it from either parties doesn't produce any good.

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

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

ARM defconfig files

[Linus Torvalds]

On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> 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.

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

ARM defconfig files

[Felipe Contreras]

On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
>> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> >
>> > When you brought up the problem you seemed absolutely convinced
>> > that nothing except your solution was going to be acceptable.
>>
>> 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.
>
> 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.

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