Am 10.03.2016 um 19:39 schrieb Andrew: > 10.03.2016 20:03, Erich Titl пишет: >> Hi Andrew >> >> Am 10.03.2016 um 18:53 schrieb Andrew: >>> Hi. >>> >>> For common config case you can easily check what real differences are >>> between configs. >>> >>> + kernel upgrade is enough easy: just update common config (be make >>> oldconfig) and try to generate other configs (looking on cdiff output - >>> for changed/missed lines); and then look on result of 'make oldconfig' + >>> maybe correct some subarch-specific settings (for ex., enable new >>> drivers for i686/x86_64). >> 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. > > 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. > >> >>> For me, migration to new kernel (when I experimented with different >>> versions due to crashes with PPPoE on 4.1) takes max 10-15 minutes - >>> even when I switched from 4.1 to old 3.2. >> Which I consider very long for just a kernel upgrade. > Not too long - it's done just once (ok, maybe - twice as in 5.2 case, > when we switched from 5.1's 3.10 to 3.14 and then to 4.1) per minor > release. Potentially with each new kernel release and at out speed that is every two weeks. > >> 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. > >> >> I looked at my routine to get master in sync with new-initrd. > It seems like you re-generated kernel config from scratch. With a lot > of completely unneeded stuff. > > I just applied your changes in your old branch to new kernel configs. > They lays perfectly. But you need the full config files to do this and then you just convert them back to diffs :-( Whatever, I _believe_ _now_ that keeping the full config files would make transition easier, mostly because of the format of the config files, which _mark_ the absence of an option instead of just leaving it out. If the config format would hold less of this non_information it would be better suited to automatic upgrades. cheers ET ------------------------------------------------------------------------------ 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