08.04.2017 22:59, Andreas Färber пишет:
Hi Michal,
Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging.
How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me.
lpae is highly different from the 64kb flavor that just tweaks one or two options - the size difference above should make that obvious: The lpae flavor excludes support for old Cortex-A8/-A9/-A5 based platforms and enables a few platforms that depend on LPAE (e.g., LSI Axxia) as well as features that depend on LPAE (e.g., KVM). So please understand that the lpae flavor is not just the equivalent to pae flavor on i386, despite similar naming!
vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one.
I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the CC'ed contributors, since during my recent absences your ARM engineers didn't even help update arm64!), I would much rather run oldconfig for lpae as a real config and risk having a default fragment break than the other way around. Switching the naming would cause problems for our JeOS images and cause even more confusion for users.
Dear All, Year or two ago I regularly submitted here config-update patches for arm. Unfortunately, I don't have much time to track new kernel releases now. But, I would like to say from my experience that I think that kernel configs might be managed better than now. Frankly speaking, the first thing I did when I needed to update ARM config was cherry-picking last arch-independent changes from x86_64 config. There are things like filesystems and network protocols. It In my personal opinion, to split out arch-independent config options would be more useful than default/lpae diffing. That would simplify ARM config maintenance at least.
Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend.
Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model.
In summary, there are delays getting updated configs submitted to your team by myself or community members, and then there are delays getting the submitted config updates merged by your team and thereby into OBS. During that timespan there are no kernels available from Kernel:HEAD ARM repo - Andreas Schwab had complained about that before, to no effect.
https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default?repos...
(Currently this only shows aarch64 binaries, no armv6l or armv7l.)
And I doubt you added any checks to stop yourselves from submitting a kernel with non-updated ARM configs to Kernel:stable, should it not get done within sufficient weeks. We had that happen for armv6l before I stepped in, I recall. Why are no alarm bells raised when, say, -rc3 still has "-!needs_updating"? Should be easy to grep for.
So the kernel team clearly does not care about the master ARM configs (I was told to monitor an internal-only mailing list to get notified about -rc1 updates disabling the configs, for external contributors that still requires to poll the Git repository - no emails to opensuse-kernel or opensuse-arm for instance), and now you propose yet another change that seems to make the ARM updating process even harder for those that do care. Thank you very much... also for not CC'ing at least me on this proposal/complaint. Subject said nothing about ARM, and we don't have any -debug flavor there, so it would seem rather unrelated.
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org