Hi.
12.03.2016 13:02, Erich Titl пишет:
> Hi Andrew
>
> Am 11.03.2016 um 18:19 schrieb Andrew:
>> 11.03.2016 16:24, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 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.
>
Sorry, I mean 'make oldconfig' here.
>
>>
>>>>>>>> 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.
>
Sorry, I again missed... I mean 'make oldconfig' here too.
And diff files are mostly used for easing kernel upgrade process and
make it's result more predictable. There's no difference how configs are
stored till we want to change config parameters/upgrade kernel.
>
>
>>>>>>>>> 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 manually
>>>> Ok, 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.
>
1. Upgrade kernel version, copy configs, generate default (=i486) 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
2. Copy default config to repo
3. Clean generated configs, run 'make build' again
4. If I have some specific new drivers that must be enabled on some arch
- then I run 'make menuconfig' or edit config file manually (with 'make
oldconfig' to ensure that no additional options hapened), and then -
re-create cdiff.
5. Try to make kernel configs for other archs (to ensure that no
arch-specific options added), if needed - enable some drivers manually,
and if config is changed - re-create cdiff
I receive kernel config that 1) have predictible set of changes and 2)
arch differences are only in drivers/platform options, networking
options are same
As you see, it isn't too hard.
------------------------------------------------------------------------------
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
