10.03.2016 22:07, Erich Titl пишет: > 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. And you'll lack, for ex., new iptables features from new kernel, and got a lot of unneeded drivers.
> >>>> 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. There's mostly no config difference between kernel patch releases. It just requires to replace kernel patch... >>> 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. >>> 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 :-( No. > 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 ------------------------------------------------------------------------------ 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
