14.03.2016 14:45, Erich Titl пишет:
> Am 14.03.2016 um 13:32 schrieb Andrew:
>> 14.03.2016 12:28, Erich Titl пишет:
>>> Hi Andre
>>>
>>> Am 12.03.2016 um 19:40 schrieb Andrew:
>>>> Hi.
>>> ...>>
>>>>> 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.
>>>>>
>>>> 1. Upgrade kernel version, copy configs,
>>> Will you have to generate the config files here using the diff files?
>> No, Just copy/rename config + cdiffs in repo in this step
> Well, in the repository there are no config files, just the default and
> cdiffs.
Right, configs are generated by 'buildtool.pl source linux' and then
'make build' into the dir
>
>>> generate default (=i486) config
>>>
>>> How do you generate this one? According to one of your last mails it
>>> should already exist as Bering_KRELEASE_.config.
>>>> by generic procedure ('make oldconfig' is called), then - break process
>>>> on next arch.
>>> Note somewhere drivers (= kernel options) that should be
>>>> enabled in some specific arches (for ex., PCI-E cards drivers) if they
>>>> exists; usually - max 3-5 devices, or even none
>>> This is the manual intervention
>> Yes, of course. In other case we'll receive a lot of trash like
>> proximity/light sensors and a lot of missed useful drivers.
> OK, so you manually select/deselect new drivers in the default config
> only, and the hope is that the diff files can take care of that. My only
> concern here is, that the diff files do not appear to play nicely with
> git rebase/merge, as those functions apply diffs to diffs.
>
> ..>
cdiff files changes specified in them options.
If there is a trouble with diff syntax - we may use different syntax for
them (for ex., "-"/"+" replace to "<"/">"
>>> If we really could just work on the default config and the diff
>>> mechanism would allow us to upgrade all existing archs automatically
>>> then I would be all for it. But to me right now, this assumption appears
>>> to be wrong.
>> You may change 'make oldconfig' into 'make olddefconfig' in makefile,
>> and got same useless semi-generic configs for all archs/subarchs like in
>> your example.
> True, it applies the default values to all new options, it does not need
> manual intervention though. If we really can use cdiffs _without_
> _touching_ them _after_ an upgrade, that would be beneficial.
Yes, cdiff just changes options that are specified into it.
>
> 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=278785231&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=278785231&iu=/4140
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
