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.
> >>>> 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. > .... >>>> release. >>> Potentially with each new kernel release and at out speed that is every >>> two weeks. >> There's mostly > Mostly is not always :-) > > no config difference between kernel patch releases. It >> just requires to replace kernel patch... > And then it is easy to just use oldconfig. There's no need to touch kernel configs at all. >>>>> 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? >>>>> 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. > Nope, I did not. I applied olddefconfig So something went completely wrong in your case. > and yes, if you are sure that > the suggested defaults from the kernel people are wrong then I had more > stuff compiled in than necessary. But if you don't trust those folks > then you better write your own kernel :-) As I said, generic config isn't a best choice. For ex, you don't need a SMP on i486/Geode. You don't need a lot of RAID drivers for Geode/i486 (physically they are missed on these platforms). You don't need SATA drivers here. And of course you don't need PCI-E cards drivers for that platforms. From other side, for i686/x86_64 you need all PCI-E network cards drivers (a lot of them are disabled - for ex., Mellanox, Emulex 10GbE and so on). And you also don't need drivers for power controllers, proximity/light sensors and a lot of other stuff targetted for mobile devices/notebooks. That's why defconfig is a bad idea. > >>>> 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. > So you just apply the diffs to a completely new kernel config? Yes. Because diffs are trivial (storage drivers are compiled as built-in instead of modules), + minor manual edit of .cdiff (for one new SATA driver that was added in 4.4 kernel) > IMHO this > is utterly dangerous. And yes, then you need to inspect the files and > you will miss stuff and after some time it will be detected and fixed. > > Still don't believe 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=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
