On 2 August 2013 01:46, Jon Medhurst (Tixy) <t...@linaro.org> wrote: > On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: >> On 1 August 2013 09:30, Ryan Harkin <ryan.har...@linaro.org> wrote: >> > The vexpress defconfig has always been broken. >> >> ...maybe we could fix it? > > It has been suggested that should be deleted as people can use the > multiplatform defconfig (though I believe that is missing the regulator > config for mmc as well). > > People have different ideas where various configs should live, boards > specific defconfig, multiplatform defconfig or in Kconfig; and any > particular change probably would have people arguing against it. And
That's probably a correct prediction... but it doesn't mean all of the solutions are equally good. I guess nobody outside Linaro with these kernels uses and most don't even know about the config fragments scripts. We inherit them from llct but nobody uses them in Fujitsu. - For things fixing a defconfig, or making it appropriate for other patches added in that kernel, shouldn't we patch the defconfig directly (via make savedefconfig)? Then people will use the fix and you have a fix to suggest upstream. - For optional things that follow from enabling a single Kconfig selection (eg, CONFIG_ANDROID) why not have it enforced at the selection of that config? - For Ubuntize or --> > with vexpress we have the added complication thrown into the mix that > people use it a lot with QEMU ;-) ...if there's something special needed for QEMU, maybe the fragments are the right answer. Or if it's just lack of models for IP maybe building the drivers modular anyway and knocking them out in dts (status="not okay") is the right answer. However currently they all have a "let's make a fat kernel" =y approach when our defconfig is more like allmodules, so for us we can't use any of the fragments meaningfully, so eliminating them doesn't sound like a bad idea. -Andy > -- > Tixy > > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
