LWN: Comments on "ARM and defconfig files"

ARM and defconfig files

wookey — 2010-07-15T12:06:13+00:00

3 years? It was 2001.

And yes, I believe CML would have largely prevented the defconfig-bloat.

ARM and BOARD config files

NightMonkey — 2010-07-03T04:13:13+00:00

Wouldn't it be nice if the board manufactures just gave you a .config file for their board? They put the effort into making the board docs, it doesn't seem like much more effort to match that spec with the kernel .config. Even if the .config they offer for download starts to get stale, you're one "make oldconfig" away from a working .config.

I can dream, can't I? ;)

ARM and BOARD config files

HalfMoon — 2010-06-28T13:47:33+00:00

Dropping defconfigs causes one new problem: no longer is it practical to just take a kernel tree and build for a board; you've got to do a bunch of homework to find some board-specific config working with that board. Consult lots of board docs (if you can even find them!) and enable all the board-specific hardware. Workable, yes, but this creates new obstacles for embedded developers. And they have too many of them already.

ARM and defconfig files

landley — 2010-06-25T19:56:24+00:00

Personally I still use miniconfigs. I submitted them several times, the kernel guys didn't want to merge them (one of those "do this huge new pile of work and then we'll think about it" things, which went on my todo list 5 years ago and is still there), but I still happily use them out of tree...

http://lwn.net/Articles/160497/
http://lwn.net/Articles/161086/
http://impactlinux.com/hg/aboriginal/file/tip/sources/toy...
http://impactlinux.com/hg/aboriginal/file/tip/sources/tar...

Not just for the kernel, either:

http://impactlinux.com/hg/aboriginal/file/tip/sources/bas...

Rob

ARM and defconfig files

Baylink — 2010-06-23T01:34:52+00:00

I'm not a kernel guy, but doesn't that final solution sound a whole lot like the CML that ESR put a bunch of work into, for naught, about 3 years back?

At least conceptually?

ARM and defconfig files

stevenb — 2010-06-19T22:22:05+00:00

I wish we had someone like Linus in the GCC community. Someone able to say, "Well, it sucks and we all know it, too! So I am going to remove it and if you care enough, you should come up with a better way!" This is the only way to keep a huge code base maintainable.

ARM and defconfig files

ppisa — 2010-06-18T00:31:29+00:00

I see as most fundamental design flaw, that config files has
not defined negative answer (CONFIG_xxx=n) as valid and stored
option. This would allow to use config fragments which could
override previously selected defaults and values from system
provided config_def files. The Debian system uses some way
how to combine config fragments already.

Other problem is, that the kconfig should allow export
of options touched by user and config file should hold
classification of value origin

kconfig_default automatic_select default_config user

This would allow fragment export even in future kconfig
based tools run. The internals of kconfig already provide
mechanisms which could be base for such options management.

ARM and defconfig files

dmag — 2010-06-17T16:12:43+00:00

Once again, Linus getting grumpy leads to neat stuff. Picking a defconfig file for a bare ARM chip brings in too much useless stuff (someone else's choices for SLAB allocator, LCD support, etc). As the article says, it's rare to use one without changes. Heck, how many people use the default x86 kernel config without changing something before compiling?

In fact, I think "make menuconfig" should save the set of "local overrides". This file could be copied from one kernel version to the next, instead of the entire .config. It will also make it trivial to see what things you've messed with.