Hi Andrew Am 11.03.2016 um 18:19 schrieb Andrew:
11.03.2016 16:24, Erich Titl пишет:Hi AndrewAm 11.03.2016 um 12:50 schrieb Andrew:11.03.2016 08:48, Erich Titl пишет:Hi Andrew Am 10.03.2016 um 21:19 schrieb Andrew:10.03.2016 22:07, Erich Titl пишет:Am 10.03.2016 um 19:39 schrieb Andrew:10.03.2016 20:03, Erich Titl пишет:...But in the end you have to do it for every arch, not only common config. Humans are notoriously weak when looking at changed/missed lines.Not always.Always, humans are just not good at that.If no options added into new kernel patch (this is 99% cases) - you don't need to touch kernel configs at all.Good, but how do you handle the new options. just leaving them away and sticking with an old config does not really cut it for me.If new option is added - kernel building stucks on 'make defconfig'.
Why do you always refer to defconfig? I did not mention it. Look at olddefconfig.
When there is usual kernel config - at kernel update there's usual tens or even hundreds new options that should be choosed. And using .cdiff with generic kernel you should only enable new platform-specific drivers; generic options like network stack are applied automatically.The same applies if you use make olddefconfig.And you'll lack, for ex., new iptables features from new kernel, and got a lot of unneeded drivers.Well, I am not that sure we are using the best of all configurations and typically the defaults are quite OK.What you mean as 'best configuration'? Default configuration that have a lot of stuff disabled (for ex., network drivers, a lot of iptables modules and so on) and a log of useless stuff enabled (for ex., video drivers are completely useless for us - we don't use graphic modes) isn't a best configuration for our case.Without knowing what new modules are provided I am not sure. Someone may use video drivers for whatnot or audio drivers for hardware I don't have. We are providing a lot of packages which I have no clue what they could be useful for.Why you think that new modules are unknown? Use 'make defconfig' - and you'll always know what is added to kernel, and what of them you enabled.
Well defconfig will use the defaults and you might not want them. Whatever. it is not merely to discuss the way to do kernel upgrade but the usefulness of the diff files. I personally doubt they are any good, but if someone thinks they are, well I could not care less. I can live with the current set-up, I don't fancy it but that is my opinion.
And you still have to generate the full config for every arch. But then time is not the only parameter to look at. We should analyze if there were non necessary steps involved in this process.In any case, you should look at configs difference - so generating some kind of diffs is necessary.Why? The kernel developers gave us pretty good tools to manage kernel upgrades and they did _not_ provide diff files. I believed in the past this was a wekness, now I am convinced they knew why.To be sure that you didn't missed something.You typically miss stuff when you do it manuallyOk, so you prefer disable all potentially useful stuff (like network drivers, some iptables modules) because these drivers disabled in default kernel config? Or in what way we may be sure that, for ex., iptables modules set is identical across all archs?If you want to assure this, then indeed you may need a diff file, but just to compare two full config files, not to generate one from the other.IMHO update in this case will be harder + there is more chances to make error in configs.
Please let us know how you do a major kernel upgrade. If you write it down, you might see that there are unnecessaty steps or you may convince me that the diff files are valuable.
cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
