[RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Alex Bennée]

It's buggy and we are not sure anyone uses it.

Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/system/deprecated.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 851dbdeb8ab..11c763383d9 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -424,6 +424,15 @@ linux-user mode) is deprecated and will be removed in a future version
 of QEMU. Support for this CPU was removed from the upstream Linux
 kernel in 2018, and has also been dropped from glibc.
 
+``ppc64abi32`` CPUs (since 5.2.0)
+'''''''''''''''''''''''''''''''''
+
+The ``ppc64abi32`` architecture has a number of issues which regularly
+trip up our CI testing and is suspected to be quite broken.
+Furthermore the maintainers are unsure what the correct behaviour
+should be and strongly suspect no one actually uses it.
+
+
 Related binaries
 ----------------
 
-- 
2.20.1

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Alex Bennée]

Alex Bennée <alex.bennee@linaro.org> writes:

> It's buggy and we are not sure anyone uses it.
>
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: Richard Henderson <rth@twiddle.net>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

A more aggressive follow-up patch which would also solve the CI failures
across the board:

--8<---------------cut here---------------start------------->8---
configure: don't enable ppc64abi32-linux-user by default

The user can still enable this explicitly but they will get a warning
at the end of configure for their troubles. This also drops any builds
of ppc64abi32 from our CI tests.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

1 file changed, 27 insertions(+), 19 deletions(-)
configure | 46 +++++++++++++++++++++++++++-------------------

modified   configure
@@ -574,6 +574,8 @@ gettext=""
 bogus_os="no"
 malloc_trim=""
 
+deprecated_features=""
+
 # parse CC options first
 for opt do
   optarg=$(expr "x$opt" : 'x[^=]*=\(.*\)')
@@ -1769,26 +1771,25 @@ if [ "$bsd_user" = "yes" ]; then
     mak_wilds="${mak_wilds} $source_path/default-configs/*-bsd-user.mak"
 fi
 
-if test -z "$target_list_exclude"; then
-    for config in $mak_wilds; do
-        default_target_list="${default_target_list} $(basename "$config" .mak)"
-    done
-else
-    exclude_list=$(echo "$target_list_exclude" | sed -e 's/,/ /g')
-    for config in $mak_wilds; do
-        target="$(basename "$config" .mak)"
-        exclude="no"
-        for excl in $exclude_list; do
-            if test "$excl" = "$target"; then
-                exclude="yes"
-                break;
-            fi
-        done
-        if test "$exclude" = "no"; then
-            default_target_list="${default_target_list} $target"
+if test -z "$target_list_exclude" -a -z "$target_list"; then
+    # if the user doesn't specify anything lets skip deprecating stuff
+    target_list_exclude=ppc64abi32-linux-user
+fi
+
+exclude_list=$(echo "$target_list_exclude" | sed -e 's/,/ /g')
+for config in $mak_wilds; do
+    target="$(basename "$config" .mak)"
+    exclude="no"
+    for excl in $exclude_list; do
+        if test "$excl" = "$target"; then
+            exclude="yes"
+            break;
         fi
     done
-fi
+    if test "$exclude" = "no"; then
+        default_target_list="${default_target_list} $target"
+    fi
+done
 
 # Enumerate public trace backends for --help output
 trace_backend_list=$(echo $(grep -le '^PUBLIC = True$' "$source_path"/scripts/tracetool/backend/*.py | sed -e 's/^.*\/\(.*\)\.py$/\1/'))
@@ -7691,7 +7692,7 @@ TARGET_SYSTBL=""
 case "$target_name" in
   i386)
     mttcg="yes"
-	gdb_xml_files="i386-32bit.xml"
+    gdb_xml_files="i386-32bit.xml"
     TARGET_SYSTBL_ABI=i386
     TARGET_SYSTBL=syscall_32.tbl
   ;;
@@ -7802,6 +7803,7 @@ case "$target_name" in
     TARGET_SYSTBL_ABI=common,nospu,32
     echo "TARGET_ABI32=y" >> $config_target_mak
     gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml"
+    deprecated_features="ppc64abi32 ${deprecated_features}"
   ;;
   riscv32)
     TARGET_BASE_ARCH=riscv
@@ -8232,6 +8234,12 @@ fi
 touch ninjatool.stamp
 fi
 
+if test -n "${deprecated_features}"; then
+    echo "Warning, deprecated features enabled."
+    echo "Please see docs/system/deprecated.rst"
+    echo "  features: ${deprecated_features}"
+fi
+
 # Save the configure command line for later reuse.
 cat <<EOD >config.status
 #!/bin/sh
--8<---------------cut here---------------end--------------->8---

-- 
Alex Bennée

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Peter Maydell]

On Fri, 4 Sep 2020 at 17:52, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> It's buggy and we are not sure anyone uses it.

> +``ppc64abi32`` CPUs (since 5.2.0)
> +'''''''''''''''''''''''''''''''''
> +
> +The ``ppc64abi32`` architecture has a number of issues which regularly
> +trip up our CI testing and is suspected to be quite broken.
> +Furthermore the maintainers are unsure what the correct behaviour
> +should be and strongly suspect no one actually uses it.

IRC discussion suggests we do know what the correct behaviour
is -- it should be "what the compat32 interface of a 64-bit
PPC kernel gives you", it's just that the code doesn't do that
(and never has?). It's like the mipsn32, mipsn32el, sparc32plus
ABIs which we also implement (hopefully correctly...)

But "this has always been broken and nobody complained" is
a good reason to deprecate anyway.

thanks
-- PMM

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Richard Henderson]

On 9/4/20 10:21 AM, Peter Maydell wrote:
> On Fri, 4 Sep 2020 at 17:52, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> It's buggy and we are not sure anyone uses it.
> 
>> +``ppc64abi32`` CPUs (since 5.2.0)
>> +'''''''''''''''''''''''''''''''''
>> +
>> +The ``ppc64abi32`` architecture has a number of issues which regularly
>> +trip up our CI testing and is suspected to be quite broken.
>> +Furthermore the maintainers are unsure what the correct behaviour
>> +should be and strongly suspect no one actually uses it.
> 
> IRC discussion suggests we do know what the correct behaviour
> is -- it should be "what the compat32 interface of a 64-bit
> PPC kernel gives you", it's just that the code doesn't do that
> (and never has?). It's like the mipsn32, mipsn32el, sparc32plus
> ABIs which we also implement (hopefully correctly...)
> 
> But "this has always been broken and nobody complained" is
> a good reason to deprecate anyway.

Indeed.  With the last sentence changed to

"For that reason the maintainers strongly suspect no one actually uses it."

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 4 Sep 2020 at 17:52, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> It's buggy and we are not sure anyone uses it.
>
>> +``ppc64abi32`` CPUs (since 5.2.0)
>> +'''''''''''''''''''''''''''''''''
>> +
>> +The ``ppc64abi32`` architecture has a number of issues which regularly
>> +trip up our CI testing and is suspected to be quite broken.
>> +Furthermore the maintainers are unsure what the correct behaviour
>> +should be and strongly suspect no one actually uses it.
>
> IRC discussion suggests we do know what the correct behaviour
> is -- it should be "what the compat32 interface of a 64-bit
> PPC kernel gives you", it's just that the code doesn't do that
> (and never has?). It's like the mipsn32, mipsn32el, sparc32plus
> ABIs which we also implement (hopefully correctly...)
>
> But "this has always been broken and nobody complained" is
> a good reason to deprecate anyway.

What about tweaking configure? Or should I just manually squash it in
all our CI configs?


-- 
Alex Bennée

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[Richard Henderson]

On 9/7/20 2:05 AM, Alex Bennée wrote:
> What about tweaking configure? Or should I just manually squash it in
> all our CI configs?

Squash in to CI, I would think.


r~

Re: [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

On Fri, Sep 04, 2020 at 05:51:40PM +0100, Alex Bennée wrote:
> It's buggy and we are not sure anyone uses it.
> 
> Cc: David Gibson <david@gibson.dropbear.id.au>
> Cc: Richard Henderson <rth@twiddle.net>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Acked-by: David Gibson <david@gibson.dropbear.id.au>

> ---
>  docs/system/deprecated.rst | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index 851dbdeb8ab..11c763383d9 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -424,6 +424,15 @@ linux-user mode) is deprecated and will be removed in a future version
>  of QEMU. Support for this CPU was removed from the upstream Linux
>  kernel in 2018, and has also been dropped from glibc.
>  
> +``ppc64abi32`` CPUs (since 5.2.0)
> +'''''''''''''''''''''''''''''''''
> +
> +The ``ppc64abi32`` architecture has a number of issues which regularly
> +trip up our CI testing and is suspected to be quite broken.
> +Furthermore the maintainers are unsure what the correct behaviour
> +should be and strongly suspect no one actually uses it.
> +
> +
>  Related binaries
>  ----------------
>  

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]