Re: [Qemu-devel] [PATCH v4 1/6] m68k: Add NeXTcube framebuffer device emulation

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 9 Jul 2019 at 08:35, Thomas Huth <huth@tuxfamily.org> wrote:
>
> The NeXTcube uses a linear framebuffer with 4 greyscale colors and
> a fixed resolution of 1120 * 832.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
>  https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
>
> and altered to fit the latest interface of the current QEMU (e.g.
> the device has been "qdev"-ified etc.).
>
> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
> ---
>  default-configs/m68k-softmmu.mak |   1 +
>  hw/display/Makefile.objs         |   1 +
>  hw/display/next-fb.c             | 145 +++++++++++++++++++++++++++++++
>  hw/m68k/Kconfig                  |   4 +
>  include/hw/m68k/next-cube.h      |   7 ++
>  5 files changed, 158 insertions(+)
>  create mode 100644 hw/display/next-fb.c
>  create mode 100644 include/hw/m68k/next-cube.h
> +static void nextfb_class_init(ObjectClass *oc, void *data)
> +{
> +    DeviceClass *dc = DEVICE_CLASS(oc);
> +
> +    set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
> +    dc->realize = nextfb_realize;
> +}
> +

Hi; this device seems to be missing a reset function and
also a vmsd pointer for the migration state. (If there
is in fact no migratable state, then a comment in the
class init function stating that helps to confirm that
it was not an accidental omission. Some day we might
provide some in-code way to say "has no migration state"
and then we could assert that vmsd wasn't accidentally
omitted; but we can't do that today.)

thanks
-- PMM