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'.
>>>>>> 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. >>>>>>> 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. > And then AFAIK olddefconfig just sets the default values to _new_ > parameters, and I agree they may be wrong. Speaking for me, I often > don't know what those new parameters are and I believe it is the same > with most others, so the default appears logical. Any kernel parameter has built-in help. > AFAIK olddefconfig does _not_ use defaults for options already set, just > for new options, so we get a new clean config file without having to > manually accept stuff. And with a lot of disabled useful drivers or kernel modules, + a lot of enabled useless... > >> >>>>>>> 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. > Not necessarily, just rebasing yielded a lot of differences for the diff > files. Maybe my originals already had a number of addidional stuff which > either existed in master at the time I applied it or were somehow added > later. So there werde quite some differences in the diff files and > rebase did not like it. I was not surprised by this as I did not even > want to imagine how a diff of a diff could ever be cleanly resolved. > > .. We may change cdiff syntax (for ex., replace '+' and '-' to '<' and '>'). > >> 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. > Right, and it might be nice to have such a config. We also want only > storage drivers compilled intt the kernel. With the advent of > modules.sqfs I don't care that much about modules anymore. If there are > a few too many, so be it if it makes somebody happy. > >> 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). > Yes, and if someone needs this driver we can always add it to modules. > But we will never be able to define the correct superset of drivers needed. In any case, it'll be better that most of useful drivers will be enabled, than when user can't run his network card because driver isn't enabled in default kernel config. > >> And you also don't need drivers for power controllers, proximity/light >> sensors and a lot of other stuff targetted for mobile devices/notebooks. > Unless someone wants to play with it. I would be happy if we could > define what purpose LEAF is meant for, but I would be wrong most of the > time. I think that nobody will install LEAF on tablet/phone... It'll be completely useless here. ------------------------------------------------------------------------------ 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
