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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Aug 27, 2026 at 06:32:43PM +0100, Peter Maydell wrote:
> On Thu, 27 Aug 2026 at 17:09, Philippe Mathieu-Daudé
> <philmd@oss.qualcomm.com> wrote:
> >
> > Hi Thomas,
> >
> > On 27/8/26 14:54, Thomas Huth wrote:
> > > On 09/10/2023 21.39, Mark Cave-Ayland wrote:
> > >> 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.
> 
> > >> 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?
> 
> > > Almost three years later, the world changed quite a bit. We're getting
> > > flooded with AI-generated bug reports now, and of course people are
> > > discovering problems in this old and neglected code, e.g.:
> > >
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4303
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4304
> > >   https://gitlab.com/qemu-project/qemu/-/work_items/4305
> >
> > Hobbyist motivated machine emulations never committed to be
> > secure. While I appreciate these bug reports for the overall
> > quality of the project, I'm taking these one as lowest priority.
> > I wouldn't even mind of closing them as WONTFIX "Thanks ...".
> 
> I agree, but also they can prompt us to look and say "actually
> this machine is no longer used / never got sufficiently
> implemented to be useful / has no maintainer" (cf musicpal).
> So the questions here are:
>  * is the machine's functionality better than it was in 2023:
>    can we boot something beyond just the firmware now?
>  * is anybody planning to actively work on it?
>  * is anybody using it?

I don't mind about the quality, as we never claim this stuff
is providing a security boundary, but I do wonder whether the
bar for merging a machine should have been higher than
"shows firmware prompt" ?

Are there other machines we have merged with that level of
very limited functionality ? 

Is it reasonable to say "boot a guest OS" is a criteria for
merging machines in future ?

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|