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
I get this
$ wc -l config/*/*
config/armv7hl/lpae is still not converted, because armv6 and armv7 are
"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.
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.
(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.
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org