Re: [OS-BUILD PATCHv15 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1862558387 Hi @eesposit, small nit. While you've updated the name in code the commit message and comment at the beginning of uki_addons.py still use the old name. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv11 1/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173690
+arch = path[-1]
+uki = path[-2]
+distro = path[-3]
+for addon_f in filenames:
+if addon_f.endswith('.addon'):
+addon_name = addon_f.replace(".addon","")
+addon_full_name =
f'{addon_name}-{uki}.{distro}.{arch}.addon.efi
I'm not sure if this directory structure is too simple. Thing is that for the
crashkernel= parameter the value is a size. We will need to provide multiple
addons for the parameter for different sizes so users can choose the best
matching one. With the directory structure you are suggesting this means that
we will need to maintain 4 sets of identical addons ((fedora, rhel)*(x86,
aarch64)). Wich will be a constant source of errors.
For configs there is the common/ directory that contains the configs that are
identical for rhel and fedora. In addtions configs contained directly in the
$flavor directory are identical for all arches (unless they explicitely
overwrite it...). Can we do the same for addons as well? That would reduce the
number of redundant definitions and makes managing the addons a lot easier.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv11 1/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173923 Is this print intentional or a leftover from debugging? -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv11 1/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173795
+cmd = [
+f'{UKIFY_PATH}', 'build',
+f'--stub={CURRENT_SYSTEMD_STUB}'
Do addons need a stub? I thought addons are just data which get parsed by the
stub contained in the UKI.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv11 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1821173591 You need to do more to make me truly happy. But having the -debug sub-rpm is a step in the right direction ;-) Although I don't see a point in shipping unsigned addons at all. Creating the addons is a simple call to ukify. Signing them is much more painful. You not only need to create and install your MOK but, when you want to make it properly, setup a full signing environment where the key is stored securely. This adds a lot of complexity and additional hardware requirements only to make sure that the MOK doesn't fall in the wrong hands. So the real value RH adds for our customers is to sign the addons so they don't need to maintain such an environment. Anyway, when the consensus is to ship the -debug addons unsigned I won't block it. We can still sign them later on when needed once we have real life experience with UKI from the field. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv5 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805849597 Thanks for the pointer -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv5 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1805835205 @berrange I find not having any debug addon way too restrictive. We do need ways to debug problems that will occur and we really should avoid asking users to install and maintain their own MOKs. Not only is managing MOKs way less user friendly but it also leads to much bigger security problems if a MOK falls into the wrong hands. Much worse than any "wrong" addon could cause. Especially as every addon is measured in the TPM so users do have a way to verify that only the allowed set of addons were loaded. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv5 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1803294332 > Regarding why we are doing this here and not in a separate rpm, @vkuznets might have a more detailed answer but the main point is that it would be easier to do it here, because addons are very lightweight and honestly we don't think we will ship many of them. In addition creating a rpm could be a more complicated process. I agree, that handling them here is easier. But I doubt that there will only be a few addons. There are a ton of debug parameters that at some point in time will be needed. Plus there are bugs that can be worked around by "setting the right parameter". Furthermore, we need the ability to disable memory hungry parameters for the kdump kernel. All in all my expectation is that the number will increase rapidly once UKIs get used more. > Regarding kernel configs, you mean redhat/build_configs.sh? Yes. Or just the directory structure in general. > It seems unlikely that we will have kernel version specific addons. The use cases discussed thus far all look like global addons. As such I think it is preferable to treat these as global addons until someone comes along with a clear use case for a version specific addon. Not sure if that is a valid scenario for CVMs, but one use case is when you have multiple UKIs installed that require different `crashkernel=` parameters. Then you need to be able to install different addons for each UKI. A similar scenario is when one of the UKIs has a bug that can be worked around by "setting the right parameter" that is otherwise beneficial. In that case you want to have version specific addons as well. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv5 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653760 Hi Emanuele, your implementation is different to what I originally suggested. But I must admit that your implementation is better. With my suggestion it would have been hard to get a reasonable name for the final addon. What I don't understand is why you are building the exact same set of addons for every kernel without adding a .uname section. The way I see it we either ship one set of addons for every arch/variant. But then it would be better to have a separate noarch rpm so we don't need to rebuild it over and over again. Or we want to be able to ship arch/variant-specific addons. But then you need to set the .uname section and a way to tell uki_addon.py to build addons only for certain archs/variants. Personally I would again simply copy what is done for the kernel configs and re-use the directory structure there (if we choose to go this way). -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv5 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1789653682 What spec are you referring to? I couldn't find the two paths you are mentioning neither in the uki spec nor any of the related systemd man pages. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2 1/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1758222615 This should by Python, shouldn't it. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2 0/2] redhat/kernel.spec: add uki_addons to create UKI kernel cmdline addons
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2917#note_1758222573 I'm also not convinced that having all the addons in a single config file makes sense. I'm looking at it from an kdump perspective. There we need to have the crashkernel= parameter on the command line. Where varies depending on the used hardware/setup. The only solution I came up with so far is to spam the system with a big number of predefined 's so users can pick the one they need. But IIUC this would require a huge amount of almost identical addon definitions in the config, which I don't think makes sense. Why don't you use a filesystem based structure similar to the kernel configs? Where the filename becomes the addon name, a comment replaces the description and, every following line is a command line to be signed. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCHv2] kernel.spec: Fix UKI naming to comply with BLS
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1355399566 ping ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCHv2] kernel.spec: Fix UKI naming to comply with BLS
From: Philipp Rudo
kernel.spec: Fix UKI naming to comply with BLS
The Boot Loader Specification (BLS) [1] suggests that type #2 entries (UKIs)
shall have the same names like type #1 entries with the exception of
the suffix being .efi instead of .conf. In particular this means that
the name for installed UKIs should be
-.efi. The same naming convention is
used by kernel-installs 90-uki-copy.install [2] in systemd v253.
Adjust the workaround to install UKIs in the kernel.spec to follow the
same naming convention in order to prevent breaking user space tools
that rely on it.
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/
[2]
https://github.com/systemd/systemd/blob/v253/src/kernel-install/90-uki-copy.install
Signed-off-by: Philipp Rudo
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -3033,10 +3033,12 @@ touch
%{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?-v:+%
%define kernel_uki_virt_scripts() \
%{expand:%%posttrans %{?1:%{1}-}uki-virt}\
mkdir -p /boot/efi/EFI/Linux\
-cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi
/boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\
+entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut
-d ' ' -f2)\
+cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi
/boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\
%{nil}\
%{expand:%%postun %{?1:%{1}-}uki-virt}\
-rm -f /boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\
+entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut
-d ' ' -f2)\
+rm -f /boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\
%{nil}
#
@@ -3320,7 +3322,7 @@ fi
%if %{with_efiuki}\
%{expand:%%files %{?3:%{3}-}uki-virt}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-virt.efi\
-%ghost
/%{image_install_path}/efi/EFI/Linux/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?3:+%{3}}-virt.efi\
+%ghost
/%{image_install_path}/efi/EFI/Linux/%{?-k:%{-k*}}%{!?-k:*}-%{KVERREL}%{?3:+%{3}}.efi\
%endif\
%if %{?3:1} %{!?3:0}\
%{expand:%%files %{3}}\
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] kernel.spec: Fix UKI naming to comply with BLS
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348622475 Uninstalling isn't a problem for type 2 entries as they are currently explicitly removed in %postun. So at least in this case you don't need to have an entry in %files. Using a wildcard was also my alternative solution. Originally I refrained from using it as you could construct situations where it doesn't work as intended. In particular you could have a dual boot system with identical kernel versions but different machine-ids. Using the wildcard could then lead to situations where system A claims ownership over a UKI installed by system B and thus breaking it. But that's more a theoretical problem. Anyway, please see v2. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] kernel.spec: Fix UKI naming to comply with BLS
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391#note_1348248892 @lgoncalv indeed I missed that line. I'm seeing two problems with it. 1) %files is determined during build but the entry token can only be determined during install so we cannot provide the exact file name here. And 2) there is no entry in %files for the corresponding type \#1 (aka. /boot/loader/entries/*.conf) either. So having an entry for type \#2 is kind of inconsistent. All in all I'm tempted to simply drop the line. Is that ok with you? Do you have a better solution for the problems described above? Thanks! ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[OS-BUILD PATCH] kernel.spec: Fix UKI naming to comply with BLS
From: Philipp Rudo
kernel.spec: Fix UKI naming to comply with BLS
The Boot Loader Specification (BLS) [1] suggests that type #2 entries (UKIs)
shall have the same names like type #1 entries with the exception of
the suffix being .efi instead of .conf. In particular this means that
the name for installed UKIs should be
-.efi. The same naming convention is
used by kernel-installs 90-uki-copy.install [2] in systemd v253.
Adjust the workaround to install UKIs in the kernel.spec to follow the
same naming convention in order to prevent breaking user space tools
that rely on it.
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/
[2]
https://github.com/systemd/systemd/blob/v253/src/kernel-install/90-uki-copy.install
Signed-off-by: Philipp Rudo
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index blahblah..blahblah 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -3033,10 +3033,12 @@ touch
%{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?-v:+%
%define kernel_uki_virt_scripts() \
%{expand:%%posttrans %{?1:%{1}-}uki-virt}\
mkdir -p /boot/efi/EFI/Linux\
-cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi
/boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\
+entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut
-d ' ' -f2)\
+cp /lib/modules/%{KVERREL}%{?1:+%{1}}/vmlinuz-virt.efi
/boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\
%{nil}\
%{expand:%%postun %{?1:%{1}-}uki-virt}\
-rm -f /boot/efi/EFI/Linux/vmlinuz-%{KVERREL}%{?1:+%{1}}-virt.efi\
+entry_token=$(kernel-install inspect | grep KERNEL_INSTALL_ENTRY_TOKEN: | cut
-d ' ' -f2)\
+rm -f /boot/efi/EFI/Linux/${entry_token}-%{KVERREL}%{?1:+%{1}}.efi\
%{nil}
#
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2391
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH] Revert "[redhat] Generate a crashkernel.default for each kernel build"
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1534#note_801910634 Hi Coiby, the commit looks good to me. Reviewed-by: Philipp Rudo ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] redhat/configs: enable IMA_ARCH_POLICY for aarch64 and s390x
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1216#note_620369878 Acked-by: Philipp Rudo ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] redhat/configs: enable IMA_ARCH_POLICY for aarch64 and s390x
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1216#note_619897346 @bmeneg I'm no longer the partner engineer for s390. Please direct s390 specific questions to @cimbrend in the future. Thanks. Having that said, the patch looks good to me and I would approve it if I weren't struggling with missing permissions at the moment... ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595925875 sure. BTW I'm joining RH so the email and accounts will still exist in the future. Nevertheless I guess it would be better if someone else takes over if we there's a delay. Don't know when I'll be back online again after I started. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595920020 @dzickusrh this MR can be build on any machine with an appropriate compiler (IIRC GCC10). Only the resulting kernel requires a z14+ to run. I know that the change is necessary. I was more afraid that there I introduce some suptle bug by accidentally enabling some config. But running make oldconfig should remedy that. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595402767 Hi, sorry for the late response. here's the v3 with what I picked up from the discussion, in particular improve the wording of the first two commit messages and leave the rest as is. While preparing v3 I noticed a nit in the first commit. In v3 I have disabled (=n) the config instead of using its default (=y) as the config requires LLD to work. I'm wondering why the pipelines didn't find this the way I see it this should have caused a build bug. I took this as a reason to have a closer look on the resulting configs and found that there are more changes than I had expected. For example on ppc CONFIG_LIVEPATCH now gets enabled, where I'm not sure if it is intended or not. At least in RHEL8 there is no livepatch support for ppc. An other example (also ppc) is CONFIG_DYNAMIC_FTRACE_WITH_REGS which also gets enabled now. What surprised me in this case is that I couldn't find a way to disable that option. Every test I made resulted in process_configs.sh to abort complaining about a configs mismatch. What confuses me is that I couldn't find any other config that selects this one. So I have no clue what overwrites my manually set value. Long story short, I'm afraid that switching to the dummy-tools is less straight forward than I thought in the first place. Thus I'm wondering if it wouldn't be better to move the change to it's own MR together with a thorough review of the resulting configs. My problem with this is that I'll be leaving my current job end of next week and thus have tons of other stuff on my mind at the moment. Meaning that someone else would need to take over that task Any comments/opinions? Thanks and sorry for the long comment Philipp ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 4/5] configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
rename from redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
rename from redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
index blahblah..blahblah 100644
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUN
[OS-BUILD PATCHv3 5/5] configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
From: Philipp Rudo configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15 Optimize ark for newer machines. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435 Signed-off-by: Philipp Rudo diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_MARCH_Z13=y diff --git a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 @@ -0,0 +1 @@ +CONFIG_MARCH_Z14=y diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 deleted file mode 100644 index blahblah..blahblah 0 --- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_TUNE_Z14=y diff --git a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 @@ -0,0 +1 @@ +CONFIG_TUNE_Z15=y diff --git a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 rename from redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 rename to redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 +++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 diff --git a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 rename from redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 rename to redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 index blahblah..blahblah 100644 --- a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 +++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 diff --git a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 rename from redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 rename to redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 index blahblah..blahblah 100644 --- a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 diff --git a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 rename from redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 rename to redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 index blahblah..blahblah 100644 --- a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 3/5] configs/process_configs.sh: make use of dummy-tools
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily switch TUNE_DEFAULT to y") unset failing configs to their
defaults. In the meantime upstream introduced the scripts/dummy-tools,
which are meant to disable cc-option checks by always returning 'y'.
Make use of the dummy-tools and revert the workaround.
Signed-off-by: Philipp Rudo
diff --git a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
deleted file mode 100644
index blahblah..blahblah 0
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
+++ /dev/null
@@ -1,4 +0,0 @@
-# Broken in commit 5474080a3a0a ("s390/Kconfig: make use of 'depends on
-# cc-option'"); refer to
-# https://lore.kernel.org/lkml/20191209164155.ga78...@dev.jcline.org/
-CONFIG_TUNE_DEFAULT=y
diff --git a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
deleted file mode 100644
index blahblah..blahblah 0
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_TUNE_Z14 is not set
diff --git a/redhat/configs/process_configs.sh
b/redhat/configs/process_configs.sh
index blahblah..blahblah 100755
--- a/redhat/configs/process_configs.sh
+++ b/redhat/configs/process_configs.sh
@@ -193,11 +193,11 @@ function commit_new_configs()
fi
echo -n "Checking for new configs in $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -s .newoptions
then
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig"
helpnewconfig >& .helpnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" helpnewconfig >& .helpnewconfig
parsenewconfigs
fi
rm .newoptions
@@ -227,7 +227,7 @@ function process_configs()
fi
echo -n "Processing $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -n "$NEWOPTIONS" && test -s .newoptions
then
@@ -252,7 +252,7 @@ function process_configs()
rm .listnewconfig
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" olddefconfig >
/dev/null || exit 1
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" olddefconfig > /dev/null || exit 1
echo "# $arch" > "$cfgtmp"
cat "$cfgorig" >> "$cfgtmp"
if test -n "$CHECKOPTIONS"
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 2/5] configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
From: Philipp Rudo
configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
These configs add option -ftrivial-auto-var-init={pattern,zero} to the
CFLAGS. This option are specific to CLANG and thus are not present on
typical developer systems using GCC. By using the dummy-tools the
cc-option check that tests if these options are present in the current
environment is disabled (i.e. always returns 'y') making the priviously
hidden configs visible. Thus explicitely disable these configs to satisfy
process_configs.sh.
Furthermore these configs are part of a 'choice' from which
CONFIG_INIT_STACK_NONE is selected.
Signed-off-by: Philipp Rudo
Cc: Ondrej Mosnacek
diff --git a/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
new file mode 100644
index blahblah..blahblah 100644
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_PATTERN is not set
diff --git a/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
new file mode 100644
index blahblah..blahblah 100644
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_ZERO is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 1/5] configs/common/aarch64: disable CONFIG_RELR
From: Philipp Rudo configs/common/aarch64: disable CONFIG_RELR This config adds option --pack-dyn-relocs=relr to the LDFLAGS. This option is specific to LLD and thus is not present on typical developer systems using LD. By using the dummy-tools the cc-option check that tests if the option is present in the current environment is disabled (i.e. always returns 'y') making the priviously hidden config visible. Thus explicitely disable the config to satisfy process_configs.sh. Signed-off-by: Philipp Rudo Cc: Mark Salter Cc: Mark Langsdorf Cc: Jeremy Linton diff --git a/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR b/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR new file mode 100644 index blahblah..blahblah 100644 --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR @@ -0,0 +1 @@ +# CONFIG_RELR is not set -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
This series aims to update the Architecture Level Set on s390 for ark to
Z14. Unfortunately this collides with a workaround introduced with
f88717cf44eb ("Temporarily switch TUNE_DEFAULT to y") to solve
configuration problems due to cc-options checks failing on the
configuration system. Thus the series was extended to solve that as well
by using the scripts/dummy-tools in process_configs.sh.
v2 -> v3:
* Disable CONFIG_RELR. Although its default is 'y' it requires LLD to work.
* Improve wording in commit message of the first two commits.
v1 -> v2:
* Move the new configs introduced by using the dummy-tools from
pending-common/ to common/ and split them to separate commits to
simplify review.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435
Signed-off-by: Philipp Rudo
---
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13
| 1 -
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
| 2 +-
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14
| 1 -
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15
| 1 +
redhat/configs/common/generic/arm/aarch64/CONFIG_RELR
| 1 +
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10 | 0
redhat/configs/fedora/generic/CONFIG_MARCH_Z13 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 | 0
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196 | 0
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900 | 0
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990 | 0
redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109 =>
redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13 | 0
redhat/configs/fedora/generic/CONFIG_TUNE_Z14 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14| 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109 | 0
redhat/configs/ark/generic/s390x/CONFIG_TUNE_ZEC12 =>
redhat/configs/common/generic/s390x/CONFIG_TUNE_ZEC12 | 0
redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
| 1 +
redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
| 1 +
redhat/configs/fedora/generic/CONFIG_MARCH_Z14 =>
redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 | 0
redhat/configs/fedora/generic/CONFIG_TUNE_DEFAULT =>
redhat/configs/fedora/generic/s390x/CONFIG_TUNE_DEFAULT| 0
redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 =>
redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 | 0
redhat/configs/fedora/generic/CONFIG_MARCH_Z10
| 1 -
redhat/configs/fedora/generic/CONFIG_MARCH_Z196
| 1 -
redhat/configs/fedora/generic/CONFIG_MARCH_Z900
| 1 -
redhat/configs/fedora/generic/CONFIG_MARCH_Z990
| 1 -
redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
| 1 -
redhat/configs/fedora/generic/CONFIG_TUNE_Z10
| 1 -
redhat/configs/fedora/generic/CONFIG_TUNE_Z13
| 1 -
redhat/configs/fedora/generic/CONFIG_TUNE_Z196
| 1 -
redhat/configs/fedora/generic/CONFIG_TUNE_Z900
| 1 -
redhat/configs/fedora/generic/CONFIG_TUNE_Z990
Re: [OS-BUILD PATCHv2 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585640564 Hi Dan, 1. If I need to push an other version I can add the Fedora update as well. This MR already got way bigger than I expected. So I don't see a problem in adding one more commit. 2. I did a quick test and this should indeed work. However I'm not sure if it's the intended behavior. My understanding so far was that common/ should contain configs that are shared between ark and fedora and not that common/ contains the defaults which can be overwritten in ark/ and fedora/. Anyway, if the maintainers agree with your suggestion I'm happy to change it. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585239426 best choice would be @dhorak1, @cohuck or @thuth ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_585224768 @dzickusrh yes, that's a fallout from using the dummy-tools. These two configs only work with clang and thus are usually hidden. Plus they are part of a choice from which CONFIG_INIT_STACK_NONE is set. Do you want me to improve the wording in the commit message? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2] configs/common/s390: disable CONFIG_QETH_{OSN,OSX}
From: Philipp Rudo
configs/common/s390: disable CONFIG_QETH_{OSN,OSX}
Shipment of the devices required for these options were ceased with z13.
With the ALS set to z14 for ark there is no need to keep the options
enabled.
v2: disable the configs for fedora as well
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1903201
Signed-off-by: Philipp Rudo
diff a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
b/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
--- a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
+++ b/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
@@ -1 +1 @@
-CONFIG_QETH_OSN=y
+# CONFIG_QETH_OSN is not set
diff a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
b/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
--- a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
+++ b/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
@@ -1 +1 @@
-CONFIG_QETH_OSX=y
+# CONFIG_QETH_OSX is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1149
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] configs/ark/s390: disable CONFIG_QETH_{OSN,OSX}
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1149#note_581194256 will do. I also asked our network people. They are in favor to remove them in fedora as well. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH] configs/ark/s390: disable CONFIG_QETH_{OSN,OSX}
From: Philipp Rudo
configs/ark/s390: disable CONFIG_QETH_{OSN,OSX}
Shipment of the devices required for these options were ceased with z13.
With the ALS set to z14 for ark there is no need to keep the options
enabled.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1903201
Signed-off-by: Philipp Rudo
diff a/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSN
b/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSN
--- /dev/null
+++ b/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSN
@@ -0,0 +1 @@
+# CONFIG_QETH_OSN is not set
diff a/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSX
b/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSX
--- /dev/null
+++ b/redhat/configs/ark/generic/s390x/CONFIG_QETH_OSX
@@ -0,0 +1 @@
+# CONFIG_QETH_OSX is not set
diff a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
b/redhat/configs/fedora/generic/s390x/CONFIG_QETH_OSN
--- a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSN
+++ b/redhat/configs/fedora/generic/s390x/CONFIG_QETH_OSN
diff a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
b/redhat/configs/fedora/generic/s390x/CONFIG_QETH_OSX
--- a/redhat/configs/common/generic/s390x/CONFIG_QETH_OSX
+++ b/redhat/configs/fedora/generic/s390x/CONFIG_QETH_OSX
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1149
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 4/5] configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_ZEC12
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_ZEC12
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_ZEC12
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_ZEC12
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z10 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z14 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z196 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z900 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z990 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z9_109 is not set
diff a/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
b/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
--- a/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_TUNE_Z10 is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an em
[OS-BUILD PATCHv2 5/5] configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
From: Philipp Rudo configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15 Optimize ark for newer machines. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435 Signed-off-by: Philipp Rudo diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 --- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_MARCH_Z13=y diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 @@ -0,0 +1 @@ +CONFIG_MARCH_Z14=y diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 --- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_TUNE_Z14=y diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 @@ -0,0 +1 @@ +CONFIG_TUNE_Z15=y diff a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 --- a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 +++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 diff a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 --- a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 +++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 diff a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 --- a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 diff a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 --- a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 2/5] configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
From: Philipp Rudo
configs/common: disable CONFIG_INIT_STACK_ALL_{PATTERN,ZERO}
Using scripts/dummy-tools disables cc-option checks by always returning
'y'. This reveals config options usually hidden on typical developer
systems (x86 + gcc), which again causes process_configs.sh to fail due
to new, unset options. Fix this by explicitely setting these config
options their defaults.
Signed-off-by: Philipp Rudo
Cc: Ondrej Mosnacek
diff a/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_PATTERN
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_PATTERN is not set
diff a/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_INIT_STACK_ALL_ZERO
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_ZERO is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 3/5] configs/process_configs.sh: make use of dummy-tools
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily switch TUNE_DEFAULT to y") unset failing configs to their
defaults. In the meantime upstream introduced the scripts/dummy-tools,
which are meant to disable cc-option checks by always returning 'y'.
Make use of the dummy-tools and revert the workaround.
Signed-off-by: Philipp Rudo
diff a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
+++ /dev/null
@@ -1,4 +0,0 @@
-# Broken in commit 5474080a3a0a ("s390/Kconfig: make use of 'depends on
-# cc-option'"); refer to
-# https://lore.kernel.org/lkml/20191209164155.ga78...@dev.jcline.org/
-CONFIG_TUNE_DEFAULT=y
diff a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_TUNE_Z14 is not set
diff a/redhat/configs/process_configs.sh b/redhat/configs/process_configs.sh
--- a/redhat/configs/process_configs.sh
+++ b/redhat/configs/process_configs.sh
@@ -193,11 +193,11 @@ function commit_new_configs()
fi
echo -n "Checking for new configs in $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -s .newoptions
then
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig"
helpnewconfig >& .helpnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" helpnewconfig >& .helpnewconfig
parsenewconfigs
fi
rm .newoptions
@@ -227,7 +227,7 @@ function process_configs()
fi
echo -n "Processing $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -n "$NEWOPTIONS" && test -s .newoptions
then
@@ -252,7 +252,7 @@ function process_configs()
rm .listnewconfig
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" olddefconfig >
/dev/null || exit 1
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" olddefconfig > /dev/null || exit 1
echo "# $arch" > "$cfgtmp"
cat "$cfgorig" >> "$cfgtmp"
if test -n "$CHECKOPTIONS"
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 1/5] configs/common/aarch64: enable CONFIG_RELR
From: Philipp Rudo configs/common/aarch64: enable CONFIG_RELR Using scripts/dummy-tools disables cc-option checks by always returning 'y'. This reveals config options usually hidden on typical developer systems (x86 + gcc), which again causes process_configs.sh to fail due to new, unset options. Fix this by explicitely setting these config options to their defaults. Signed-off-by: Philipp Rudo Cc: Mark Salter Cc: Mark Langsdorf Cc: Jeremy Linton diff a/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR b/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR --- /dev/null +++ b/redhat/configs/common/generic/arm/aarch64/CONFIG_RELR @@ -0,0 +1 @@ +CONFIG_RELR=y -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
This series aims to update the Architecture Level Set on s390 for ark to
Z14. Unfortunately this collides with a workaround introduced with
f88717cf44eb ("Temporarily switch TUNE_DEFAULT to y") to solve
configuration problems due to cc-options checks failing on the
configuration system. Thus the series was extended to solve that as well
by using the scripts/dummy-tools in process_configs.sh.
v1 -> v2:
* Move the new configs introduced by using the dummy-tools from
pending-common/ to common/ and split them to separate commits to
simplify review.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435
Signed-off-by: Philipp Rudo
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH 0/3] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_579786679 ok, I naively thought that pending-common was the staging area and everything contained in it will be included in the next round of config review. What's the correct way to proceed? Not having them set isn't an option for me as that would break 'make dis-configs'. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH 3/3] configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15
From: Philipp Rudo configs/ark/s390: set CONFIG_MARCH_Z14 and CONFIG_TUNE_Z15 Optimize ark for newer machines. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1876435 Signed-off-by: Philipp Rudo diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 --- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z13 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_MARCH_Z13=y diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14 @@ -0,0 +1 @@ +CONFIG_MARCH_Z14=y diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 --- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z14 +++ /dev/null @@ -1 +0,0 @@ -CONFIG_TUNE_Z14=y diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 --- /dev/null +++ b/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z15 @@ -0,0 +1 @@ +CONFIG_TUNE_Z15=y diff a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 --- a/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z13 +++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z13 diff a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 --- a/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z14 +++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z14 diff a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 --- a/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_MARCH_Z14 diff a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 --- a/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z15 +++ b/redhat/configs/fedora/generic/s390x/CONFIG_TUNE_Z15 -- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH 2/3] configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
From: Philipp Rudo
configs/common/s390: Clean up CONFIG_{MARCH,TUNE}_Z*
Most of the configs are identical for fedora and ark so move them to
common/generic/s390x.
While at it move the remaining configs in fedora/generic to
fedora/generic/s390x.
Signed-off-by: Philipp Rudo
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z10
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z14
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z14
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z196
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z900
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z990
diff a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
--- a/redhat/configs/ark/generic/s390x/CONFIG_MARCH_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_MARCH_Z9_109
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z10
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z10
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z13
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z13
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z196
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z196
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z900
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z900
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z990
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z990
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_Z9_109
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_Z9_109
diff a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_ZEC12
b/redhat/configs/common/generic/s390x/CONFIG_TUNE_ZEC12
--- a/redhat/configs/ark/generic/s390x/CONFIG_TUNE_ZEC12
+++ b/redhat/configs/common/generic/s390x/CONFIG_TUNE_ZEC12
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z10
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z10 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z14
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z14 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z196
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z196 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z900
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z900 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z990
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z990 is not set
diff a/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
b/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
--- a/redhat/configs/fedora/generic/CONFIG_MARCH_Z9_109
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_MARCH_Z9_109 is not set
diff a/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
b/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
--- a/redhat/configs/fedora/generic/CONFIG_TUNE_Z10
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_TUNE_Z10 is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an em
[OS-BUILD PATCH 1/3] configs/process_configs.sh: make use of dummy-tools
From: Philipp Rudo
configs/process_configs.sh: make use of dummy-tools
Using cc-option adds a dependency on the compiler in the configuration
environment. This usually breaks the config creation when the target
architecture is not the host architecture. As a remedy f88717cf44eb
("Temporarily switch TUNE_DEFAULT to y") unset failing configs to their
defaults. In the meantime upstream introduced the scripts/dummy-tools,
which are meant to disable cc-option checks by always returning 'y'.
Make use of the dummy-tools and revert the workaround.
Using the dummy-tools process_configs.sh finds new unset configs. These
are added to pending-common and set to their default.
Signed-off-by: Philipp Rudo
diff a/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_PATTERN
b/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_PATTERN
--- /dev/null
+++ b/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_PATTERN
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_PATTERN is not set
diff a/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_ZERO
b/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_ZERO
--- /dev/null
+++ b/redhat/configs/pending-common/generic/CONFIG_INIT_STACK_ALL_ZERO
@@ -0,0 +1 @@
+# CONFIG_INIT_STACK_ALL_ZERO is not set
diff a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_RELR
b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_RELR
--- /dev/null
+++ b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_RELR
@@ -0,0 +1 @@
+CONFIG_RELR=y
diff a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_DEFAULT
+++ /dev/null
@@ -1,4 +0,0 @@
-# Broken in commit 5474080a3a0a ("s390/Kconfig: make use of 'depends on
-# cc-option'"); refer to
-# https://lore.kernel.org/lkml/20191209164155.ga78...@dev.jcline.org/
-CONFIG_TUNE_DEFAULT=y
diff a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
b/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
--- a/redhat/configs/pending-common/generic/s390x/CONFIG_TUNE_Z14
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_TUNE_Z14 is not set
diff a/redhat/configs/process_configs.sh b/redhat/configs/process_configs.sh
--- a/redhat/configs/process_configs.sh
+++ b/redhat/configs/process_configs.sh
@@ -193,11 +193,11 @@ function commit_new_configs()
fi
echo -n "Checking for new configs in $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -s .newoptions
then
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig"
helpnewconfig >& .helpnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" helpnewconfig >& .helpnewconfig
parsenewconfigs
fi
rm .newoptions
@@ -227,7 +227,7 @@ function process_configs()
fi
echo -n "Processing $cfg ... "
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" listnewconfig >&
.listnewconfig
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" listnewconfig >& .listnewconfig
grep -E 'CONFIG_' .listnewconfig > .newoptions
if test -n "$NEWOPTIONS" && test -s .newoptions
then
@@ -252,7 +252,7 @@ function process_configs()
rm .listnewconfig
- make ARCH="$arch" KCONFIG_CONFIG="$cfgorig" olddefconfig >
/dev/null || exit 1
+ make ARCH="$arch" CROSS_COMPILE=scripts/dummy-tools/
KCONFIG_CONFIG="$cfgorig" olddefconfig > /dev/null || exit 1
echo "# $arch" > "$cfgtmp"
cat "$cfgorig" >> "$cfgtmp"
if test -n "$CHECKOPTIONS"
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[OS-BUILD PATCH 0/3] ark: Set Architecture Level Set to Z14 for s390
From: Philipp Rudo on gitlab.com Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144 The last commit addresses https://bugzilla.redhat.com/show_bug.cgi?id=1876435 and is preceded by two cleanups. The first commit is strictly speaking independent. If requested I can move it to a separate MR. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv4] [redhat] New configs in crypto/Kconfig
From: Philipp Rudo on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/698#note_538633814 I don't see a reason for keeping them for the zfcpdump kernel. It should be safe to remove them. BTW, I guess having CONFIG_MODULES disabled for the zfcpdump kernel is the reason why they were overridden to =y. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[OS-BUILD PATCHv2] [redhat] spec: package decompressor vmlinux for s390
From: Philipp Rudo
[redhat] spec: package decompressor vmlinux for s390
On s390 more and more code from the early boot stage is moved to the
decompressor. With this the code complexity and thus the chances to
introduce bugs increases. In order to be able to debug these early boot
bugs package the decompressors vmlinux together with the other debuginfo
for s390.
This change requires kernel commit 7a84ffc0471f ("s390/boot: add
build-id to decompressor") to work.
Upstream Status: RHEL only
Signed-off-by: Philipp Rudo
diff a/redhat/kernel.spec.template b/redhat/kernel.spec.template
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -396,6 +396,7 @@ Summary: The Linux kernel
%define hdrarch s390
%define all_arch_configs kernel-%{version}-s390x.config
%define kernel_image arch/s390/boot/bzImage
+%define vmlinux_decompressor arch/s390/boot/compressed/vmlinux
%endif
%ifarch %{arm}
@@ -1796,6 +1797,16 @@ BuildKernel() {
#
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
+if [ -n "%{vmlinux_decompressor}" ]; then
+ eu-readelf -n %{vmlinux_decompressor} | grep "Build ID" | awk
'{print $NF}' > vmlinux.decompressor.id
+ # Without build-id the build will fail. But for s390 the build-id
+ # wasn't added before 5.11. In case it is missing prefer not
+ # packaging the debuginfo over a build failure.
+ if [ -s vmlinux.decompressor.id ]; then
+ cp vmlinux.decompressor.id
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build/vmlinux.decompressor.id
+ cp %{vmlinux_decompressor}
$RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux.decompressor
+ fi
+fi
%endif
find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
[OS-BUILD PATCH] [redhat] spec: package decompressor vmlinux for s390
From: Philipp Rudo
[redhat] spec: package decompressor vmlinux for s390
On s390 more and more code from the early boot stage is moved to the
decompressor. With this the code complexity and thus the chances to
introduce bugs increases. In order to be able to debug these early boot
bugs package the decompressors vmlinux together with the other debuginfo
for s390.
This change requires kernel commit 7a84ffc0471f ("s390/boot: add
build-id to decompressor") to work.
Upstream Status: RHEL only
Signed-off-by: Philipp Rudo
diff a/redhat/kernel.spec.template b/redhat/kernel.spec.template
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -396,6 +396,7 @@ Summary: The Linux kernel
%define hdrarch s390
%define all_arch_configs kernel-%{version}-s390x.config
%define kernel_image arch/s390/boot/bzImage
+%define vmlinux_decompressor arch/s390/boot/compressed/vmlinux
%endif
%ifarch %{arm}
@@ -1796,6 +1797,16 @@ BuildKernel() {
#
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
+if [ -n "%{vmlinux_decompressor}" ]; then
+ eu-readelf -n %{vmlinux_decompressor} | grep "Build ID" | awk
'{print $NF}' > vmlinux.decompressor.id
+ # Without build-id the build will fail. But for s390 the build-id
+ # wasn't added before 5.11. In case it is missing prefer not
+ # packaging the debuginfo over a build failure.
+ if [ -s vmlinux.decompressor.id ]; then
+ cp vmlinux.decompressor.id
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build/vmlinux.decompressor.id
+ cp %{vmlinux_decompressor}
$RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux.decompressor
+ fi
+fi
%endif
find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/883
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
