[PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Thomas Huth]

The machine is incomplete, and unfortunately the hoped-for improvements
never happened. So it's maybe best if we mark this machine as deprecated
and finally remove it again in case it gets into the way of a code
refactoring or other reasons.

Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
 docs/about/deprecated.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 3b074b9ed4..2f6dadd12f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
 better reflects the way this property affects all random data within
 the device tree blob, not just the ``kaslr-seed`` node.
 
+``next-cube`` m68k machine (since 8.2)
+''''''''''''''''''''''''''''''''''''''
+
+The machine never got fully implemented and can only show the firmware prompt.
+Given the incomplete state and slow progress on improvements, it might get
+removed again without replacement.
+
+
 Backend options
 ---------------
 
-- 
2.41.0

Re: [PATCH] docs/about: Deprecate the 'next-cube' m68k machine

[Mark Cave-Ayland]

On 07/10/2023 08:23, Thomas Huth wrote:

(added Natalia who was the GSoC mentor for the NeXT cube work)

> The machine is incomplete, and unfortunately the hoped-for improvements
> never happened. So it's maybe best if we mark this machine as deprecated
> and finally remove it again in case it gets into the way of a code
> refactoring or other reasons.
> 
> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
> ---
>   docs/about/deprecated.rst | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 3b074b9ed4..2f6dadd12f 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -253,6 +253,14 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
>   better reflects the way this property affects all random data within
>   the device tree blob, not just the ``kaslr-seed`` node.
>   
> +``next-cube`` m68k machine (since 8.2)
> +''''''''''''''''''''''''''''''''''''''
> +
> +The machine never got fully implemented and can only show the firmware prompt.
> +Given the incomplete state and slow progress on improvements, it might get
> +removed again without replacement.
> +
> +
>   Backend options
>   ---------------

I'm torn a bit by this one - on the one hand the NeXT code could do with some love, 
but then given that the code already uses qdev/QOM then there isn't really much in 
the way of maintenance burden. The main concern for me at the moment is the use of 
the old-style memory accessors that pre-date the memory API.

With my latest ESP patches I think it shouldn't be too hard to update the NeXT DMA 
controller to get SCSI working, so perhaps we can leave it for now if it doesn't 
cause too many problems?

Natalia, any comments from your side? In particular what sources did you point Bryce 
towards in order to reverse engineer the NeXT hardware?


ATB,

Mark.