On Wed, Jul 4, 2012 at 11:45 AM, Christian Robottom Reis <k...@linaro.org> wrote: > On Wed, Jul 04, 2012 at 11:01:20AM +0100, Jon Medhurst (Tixy) wrote: >> > > I notice the new ubuntu.conf seems to contain everything including the >> > > kitchen sink. It has things which (as people found out at release time) >> > > breaks networking and MMC on vexpress (CONFIG_REGULATORS) and it >> > > contains drivers and other support for loads of hardware which isn't >> > > present on any Linaro supported device; and if it was, should go in the >> > > board specific config fragments, not the Ubuntu one. >> > >> > This config is basically provided by the official ubuntu kernel >> > packages. We just removed a few specific devices, and some which would >> > not make much sense, but other then that it's basically the same one >> > you can find at your desktop. >> > >> > It's useful to enable all these additional configs for a bunch of >> > reasons, like sharing with Ubuntu, enabling additional usb-based >> > devices and such. We have tons of bugs requesting us to add stuff to >> > the kernel config, and having this config fragment solves them all. >> > >> > If there's any hardware specific thing that could be disabled, we >> > could just move to the board config. Regarding CONFIG_REGULATORS, I >> > just decided to disable it at the vexpress.conf, as it only breaks >> > stuff at vexpress (and makes sense to track it there). >> >> Well, the other boards which need regulators already enable it, so >> there's not really any need for Ubuntu to have this config. This >> particular issue isn't worth worrying about - we'll be adding regulators >> to vexpress to enable the single kernel image initiative - but it does >> seem to show up a general issue of the blurring of the purpose of config >> fragments; if Ubuntu enables a bunch of hardware support, what is the >> roll of the board config fragments? > > Generally, I'd like it that the distribution flavor avoided specifying > hardware support config, as Tixy says. I realize this clashes with the > goal to stay as close as possible to the stock distro configuration, but > that's also not a end-goal in itself -- ideally, Ubuntu adopts config > fragments themselves and leaves the hardware-specific configs to be > enabled by board frags.
That's our goal. Currently it's yet perfect because it's actually a pain to update all those config sets, as it'd require at least a kernel build (which could cause failures and other extra bugs). From my personal experience, working on updating configs is a PITA, as once you enable a few other configs, things can break heavily (as the config combinations are not properly tested still). > Is there a way we can achieve this without causing more problems than we > are solving? We're getting there. If you see the amount of bugs we were able to close but just using the current config sets you'd be surprised how useful it was for the previous cycle :-) This was the first time we used it, so not getting it perfect at first is expected ;-) Cheers, -- Ricardo Salveti de Araujo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
