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

Reply via email to