Adding in Linaro Dev list for more visibility...
On Tue, 2012-07-03 at 14:08 -0300, Ricardo Salveti wrote:
On Tue, Jul 3, 2012 at 10:22 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Hi Ricardo
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?
I noticed that the Ubuntu config was patched to remove ATH6KL with the commit title "should be platform dependent". What was the reasoning for singling that driver out?
I think that for vexpress at least, you have used ubuntu-minimal.conf for the 12.06 release and the current CI jobs. What is the plan going forward? To me, it would seem to make more sense to start with the minimal config and add things as they are found to be missing.
We tried in the past, but that's just too painful. This time we decided to give the Ubuntu config a try, and then just disable what we know will not be used.
If possible, we'd like to continue using it, and change as needed to disable whatever you think it shouldn't be there.
OK, lets see how it goes.
I would like to keep the ubuntu-minimal.conf around and supported, if for no other that selfish reasons as it produces a much smaller (quicker to load) kernel and quicker builds, which is useful for anyone wanting to basic kernel development and testing. (In an ideal world it could be used on nano and developer images but that isn't worth the complexity of a second kernel package and hwpack.)
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.
Is there a way we can achieve this without causing more problems than we are solving?
On Wed, Jul 4, 2012 at 7:01 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Adding in Linaro Dev list for more visibility...
On Tue, 2012-07-03 at 14:08 -0300, Ricardo Salveti wrote:
On Tue, Jul 3, 2012 at 10:22 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Hi Ricardo
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?
As we're currently using, the board config fragments would be the basic input for any hardware specific config set for that flavour. I agree here that we'd need to move the most we can from the ubuntu.conf to the boards config, so we could try to remove any hw specific config from there.
This is currently done at this way as it was basically a copy from the current Ubuntu packages + a few removals. Unfortunately the list of configs are just huge to look at each and then update all the fragments later, as it'd require at least a kernel build for all flavours. Hopefully this will improve once we start building it daily, and cleaning it up even more.
I noticed that the Ubuntu config was patched to remove ATH6KL with the commit title "should be platform dependent". What was the reasoning for singling that driver out?
That's a bug at the driver, which breaks the kernel build in case you're selecting something that you don't have available at your system. I don't remember the details, but we were forced to remove the module for now and just enable it at origen.
I think that for vexpress at least, you have used ubuntu-minimal.conf for the 12.06 release and the current CI jobs. What is the plan going forward? To me, it would seem to make more sense to start with the minimal config and add things as they are found to be missing.
We tried in the past, but that's just too painful. This time we decided to give the Ubuntu config a try, and then just disable what we know will not be used.
If possible, we'd like to continue using it, and change as needed to disable whatever you think it shouldn't be there.
OK, lets see how it goes.
I would like to keep the ubuntu-minimal.conf around and supported, if for no other that selfish reasons as it produces a much smaller (quicker to load) kernel and quicker builds, which is useful for anyone wanting to basic kernel development and testing. (In an ideal world it could be used on nano and developer images but that isn't worth the complexity of a second kernel package and hwpack.)
Yup, this config will still be maintained as well, basically for the same reasons you described :-)
Let's see how it goes, but the goal is to clean the ubuntu.conf a bit, and update ubuntu-minimal.conf in case we're missing something there.
Cheers,
On Wed, Jul 4, 2012 at 11:45 AM, Christian Robottom Reis kiko@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,