Re: [Qemu-devel] [PATCH v4 2/6] m68k: Add NeXTcube keyboard device

[Thomas Huth]

On 03/09/2019 11.12, Peter Maydell wrote:
> On Sat, 31 Aug 2019 at 06:19, Thomas Huth <address@hidden> wrote:
>>
>> Am Tue, 13 Aug 2019 11:16:44 +0100
>> schrieb Peter Maydell <address@hidden>:
>>
>>> On Tue, 9 Jul 2019 at 08:35, Thomas Huth <address@hidden> wrote:
>>>>
>>>> It is likely still quite incomplete (e.g. mouse and interrupts are
>>>> not implemented yet), but it is good enough for keyboard input at
>>>> the firmware monitor.
>>>> 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-kbd.c
>>>>
>>>> and altered to fit the latest interface of the current QEMU (e.g.
>>>> to use memory_region_init_io() instead of
>>>> cpu_register_physical_memory()).
>>>>
>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>> +static void nextkbd_class_init(ObjectClass *oc, void *data)
>>>> +{
>>>> +    DeviceClass *dc = DEVICE_CLASS(oc);
>>>> +
>>>> +    set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
>>>> +    dc->realize = nextkbd_realize;
>>>> +    dc->reset = nextkbd_reset;
>>>> +}
>>>
>>> This one definitely needs migration state...
>>
>> m68k machines are currently unmigratable - see vmstate_m68k_cpu in
>> target/m68k/cpu.c. So I assume it's currently enough if I add a
>> ".unmigratable = 1" here, too?
> 
> Well, if you insist I guess. But personally I find it's just
> as easy to simply implement migration state.

My main concern is testing - if there is no way to test it, I can only
implement this in a hit-or-miss style, which I really don't like (though
it might be easy for such a simple device). So for the time being,
marking it with ".unmigratable = 1" and a proper TODO comments sounds
like the best solution to me.

 Thomas