[Qemu-devel] List of files containing devices which have not been QOMified

[Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

I had an idea for how to get a rough list of source files
containing devices that haven't been QOMified. The theory
is that a pre-QOM device generally has an "init" function
which allocates memory for the device struct. So looking in
hw/ for files which call g_new*() or g_malloc*() should get
us all the non-QOM devices (as well as a pile of false
positives, of course). The following link is the result of
doing that and then eyeballing the results for false positives
and throwing those out. It might have missed one or two
files or included one or two by mistake. But I think it's
pretty close, and it seems to have caught all the obvious
ones I knew about. There are 61 files on this list.

I am also suspicious about hw/bt/ but don't know enough
about that subsystem to say if it could benefit from
using QOM objects more.

hw/arm/exynos4210.c
hw/arm/nseries.c
hw/arm/omap1.c
hw/arm/omap2.c
hw/arm/pxa2xx.c
hw/arm/stellaris.c
hw/arm/strongarm.c
hw/char/omap_uart.c
hw/char/parallel.c
hw/char/serial.c
hw/char/sh_serial.c
hw/core/ptimer.c
hw/cris/axis_dev88.c
hw/display/blizzard.c
hw/display/omap_dss.c
hw/display/omap_lcdc.c
hw/display/pxa2xx_lcd.c
hw/display/tc6393xb.c
hw/display/vga-isa-mm.c
hw/dma/etraxfs_dma.c
hw/dma/omap_dma.c
hw/dma/rc4030.c
hw/dma/soc_dma.c
hw/i2c/bitbang_i2c.c
hw/ide/ahci.c
hw/input/pckbd.c
hw/input/ps2.c
hw/input/pxa2xx_keypad.c
hw/input/stellaris_input.c
hw/input/tsc2005.c
hw/input/tsc210x.c
hw/m68k/mcf5206.c
hw/m68k/mcf5208.c
hw/mips/mips_malta.c
hw/misc/cbus.c
hw/misc/omap_clk.c
hw/misc/omap_gpmc.c
hw/misc/omap_l4.c
hw/misc/omap_sdrc.c
hw/openrisc/cputimer.c
hw/pci/shpc.c ?
hw/ppc/ppc405_boards.c
hw/ppc/ppc405_uc.c
hw/ppc/ppc440_uc.c
hw/ppc/ppc4xx_devs.c
hw/ppc/ppc_booke.c
hw/ppc/prep.c
hw/riscv/riscv_htif.c
hw/riscv/sifive_uart.c
hw/sd/omap_mmc.c
hw/sh4/r2d.c
hw/sh4/sh7750.c
hw/sparc64/sparc64.c
hw/ssi/omap_spi.c
hw/timer/arm_timer.c
hw/timer/mips_gictimer.c
hw/timer/omap_gptimer.c
hw/timer/omap_synctimer.c
hw/timer/sh_timer.c
hw/usb/hcd-musb.c
hw/xtensa/xtfpga.c

thanks
-- PMM

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Philippe Mathieu-Daudé]

On 6/11/18 19:43, Peter Maydell wrote:
> I had an idea for how to get a rough list of source files
> containing devices that haven't been QOMified. The theory
> is that a pre-QOM device generally has an "init" function
> which allocates memory for the device struct. So looking in
> hw/ for files which call g_new*() or g_malloc*() should get
> us all the non-QOM devices (as well as a pile of false
> positives, of course). The following link is the result of
> doing that and then eyeballing the results for false positives
> and throwing those out. It might have missed one or two
> files or included one or two by mistake. But I think it's
> pretty close, and it seems to have caught all the obvious
> ones I knew about. There are 61 files on this list.
> 
> I am also suspicious about hw/bt/ but don't know enough
> about that subsystem to say if it could benefit from
> using QOM objects more.
> 

> hw/arm/exynos4210.c
I already did this one.

 > hw/sd/omap_mmc.c
I will do this one.

 > hw/mips/mips_malta.c
 > hw/timer/mips_gictimer.c
I'm interested in doing those two.

> hw/char/parallel.c
> hw/char/serial.c
> hw/display/vga-isa-mm.c
> hw/input/pckbd.c
> hw/input/ps2.c
I can do those too when QOM'ifying the Malta.

> hw/char/sh_serial.c
> hw/sh4/r2d.c
> hw/sh4/sh7750.c
 > hw/timer/sh_timer.c
If nobody volonteers, I can take those.

Regards,

Phil.

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 06/11/2018 19:43, Peter Maydell wrote:
> hw/pci/shpc.c ?

This is not a device, it is a PCI capability.

Paolo

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 06/11/2018 19:43, Peter Maydell wrote:
> hw/core/ptimer.c

Not a device.

> hw/i2c/bitbang_i2c.c

TYPE_GPIO_I2C?

> hw/ide/ahci.c

Even though AHCIState is not a QOM object, all of its users are
(TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c).

Paolo

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Alistair Francis]

On Tue, Nov 6, 2018 at 11:47 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 06/11/2018 19:43, Peter Maydell wrote:
> > hw/core/ptimer.c
>
> Not a device.
>
> > hw/i2c/bitbang_i2c.c
>
> TYPE_GPIO_I2C?
>
> > hw/ide/ahci.c
>
> Even though AHCIState is not a QOM object, all of its users are
> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c).

Should this list go on the wiki somewhere? Then we can cross off ones
as they are converted.

Alistair

>
> Paolo
>

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[John Snow]

On 11/06/2018 02:46 PM, Paolo Bonzini wrote:
> On 06/11/2018 19:43, Peter Maydell wrote:

>> hw/ide/ahci.c
> 
> Even though AHCIState is not a QOM object, all of its users are
> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c).
> 

Yeah, if there's something *further* that needs to happen, let me know.
I'm not sure what the QOM ideal is.

Is there a reference implementation for what we consider to be a proper
QOM device that I can measure against?

A list of forbidden ABIs I ought not use?

(S/ATA device realization is in itself already particularly bizarre
where we have a skeleton list of properties in QOM and then we just
malloc the bulk of the structure we actually use, but I think it's not
worth fixing to be nicer because I haven't figured out a way to do it
without breaking backwards compatibility, so I've just left it alone.)

--js

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 06/11/2018 22:23, John Snow wrote:
> 
> 
> On 11/06/2018 02:46 PM, Paolo Bonzini wrote:
>> On 06/11/2018 19:43, Peter Maydell wrote:
> 
>>> hw/ide/ahci.c
>>
>> Even though AHCIState is not a QOM object, all of its users are
>> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c).
> 
> Yeah, if there's something *further* that needs to happen, let me know.
> I'm not sure what the QOM ideal is.

I think it's okay.  The virtio-*-device approach (which is contained in
virtio-*-pci and virtio-*-ccw) made sense for virtio where you could
have "socket" virtio-mmio devices and the virtio-*-device "plugs" are
specified in the command line.  However, for AHCI it's overkill.

Paolo

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

On 6 November 2018 at 19:46, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 06/11/2018 19:43, Peter Maydell wrote:
>> hw/core/ptimer.c
>
> Not a device.

Indeed not, but it could be a QOM object I guess (would
that gain us anything?)

>> hw/i2c/bitbang_i2c.c
>
> TYPE_GPIO_I2C?

That part is, but bitbang_i2c_init() creates an object
which isn't a QOM object and is used by some other i2c devices.

>> hw/ide/ahci.c
>
> Even though AHCIState is not a QOM object, all of its users are
> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c)

Mmm, this is one of those which I was unsure about so
put on the list anyway.

Overall something that occurs to me is that I'm not sure
what exactly (other than tidiness) we gain from converting
remaining non-QOM devices. In some of the other cases I've
looked at (like sysbus init methods or old_mmio users) we
get to complete an API transition and remove the old code.
For a non-QOM device, how much does it hurt us that they're
lying around in the codebase? We might do better to
specifically target APIs we'd like to deal with (like
direct uses of vmstate_register, maybe?).

Some bits I would definitely like to see cleaned up are
the things like the mmio version of the 16550 UART code
in hw/char/serial.c -- that not being QOMified has
knock-on effects in making other devices that would
like to basically just be 16550-wrappers harder to
write in a clean way.

thanks
-- PMM

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

On 6 November 2018 at 19:16, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On 6/11/18 19:43, Peter Maydell wrote:
>>
>> I had an idea for how to get a rough list of source files
>> containing devices that haven't been QOMified. The theory
>> is that a pre-QOM device generally has an "init" function
>> which allocates memory for the device struct. So looking in
>> hw/ for files which call g_new*() or g_malloc*() should get
>> us all the non-QOM devices (as well as a pile of false
>> positives, of course). The following link is the result of
>> doing that and then eyeballing the results for false positives
>> and throwing those out. It might have missed one or two
>> files or included one or two by mistake. But I think it's
>> pretty close, and it seems to have caught all the obvious
>> ones I knew about. There are 61 files on this list.
>>
>> I am also suspicious about hw/bt/ but don't know enough
>> about that subsystem to say if it could benefit from
>> using QOM objects more.
>>
>
>> hw/arm/exynos4210.c
>
> I already did this one.
>
>> hw/sd/omap_mmc.c
> I will do this one.

I have some out-of-tree stuff that deals with this device
(part of the omap3 patchset tries to do some QOMification,
but it was a bit tangled with adding omap3 features),
so if you could hold off on working on the various omap
devices in this set that might be better, til I see
whether any of the out-of-tree code is usefully salvageable.

thanks
-- PMM

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 07/11/2018 00:05, Peter Maydell wrote:
> On 6 November 2018 at 19:46, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 06/11/2018 19:43, Peter Maydell wrote:
>>> hw/core/ptimer.c
>>
>> Not a device.
> 
> Indeed not, but it could be a QOM object I guess (would
> that gain us anything?)

I don't know, it seems to me more like a generic high-level abstraction
around QEMUTimer.

>>> hw/i2c/bitbang_i2c.c
>>
>> TYPE_GPIO_I2C?
> 
> That part is, but bitbang_i2c_init() creates an object
> which isn't a QOM object and is used by some other i2c devices.

Ah, I see.  Then I think it is in the same family as AHCIState.

>>> hw/ide/ahci.c
>>
>> Even though AHCIState is not a QOM object, all of its users are
>> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c)
> 
> Mmm, this is one of those which I was unsure about so
> put on the list anyway.
> 
> Overall something that occurs to me is that I'm not sure
> what exactly (other than tidiness) we gain from converting
> remaining non-QOM devices. In some of the other cases I've
> looked at (like sysbus init methods or old_mmio users) we
> get to complete an API transition and remove the old code.
> For a non-QOM device, how much does it hurt us that they're
> lying around in the codebase? We might do better to
> specifically target APIs we'd like to deal with (like
> direct uses of vmstate_register, maybe?).

Yes, those are ugly and are definitely a sign of a legacy device
(non-qdev even before QOM).  serial_mm_init is the main example as you
point out below.

Paolo

> Some bits I would definitely like to see cleaned up are
> the things like the mmio version of the 16550 UART code
> in hw/char/serial.c -- that not being QOMified has
> knock-on effects in making other devices that would
> like to basically just be 16550-wrappers harder to
> write in a clean way.

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Philippe Mathieu-Daudé]

On 7/11/18 0:06, Peter Maydell wrote:
> On 6 November 2018 at 19:16, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> On 6/11/18 19:43, Peter Maydell wrote:
>>>
>>> I had an idea for how to get a rough list of source files
>>> containing devices that haven't been QOMified. The theory
>>> is that a pre-QOM device generally has an "init" function
>>> which allocates memory for the device struct. So looking in
>>> hw/ for files which call g_new*() or g_malloc*() should get
>>> us all the non-QOM devices (as well as a pile of false
>>> positives, of course). The following link is the result of
>>> doing that and then eyeballing the results for false positives
>>> and throwing those out. It might have missed one or two
>>> files or included one or two by mistake. But I think it's
>>> pretty close, and it seems to have caught all the obvious
>>> ones I knew about. There are 61 files on this list.
>>>
>>> I am also suspicious about hw/bt/ but don't know enough
>>> about that subsystem to say if it could benefit from
>>> using QOM objects more.
>>>
>>
>>> hw/arm/exynos4210.c
>>
>> I already did this one.
>>
>>> hw/sd/omap_mmc.c
>> I will do this one.
> 
> I have some out-of-tree stuff that deals with this device
> (part of the omap3 patchset tries to do some QOMification,
> but it was a bit tangled with adding omap3 features),
> so if you could hold off on working on the various omap
> devices in this set that might be better, til I see
> whether any of the out-of-tree code is usefully salvageable.

Sure, go ahead with OMAP, this is the last thing I want to touch.

I wondered if there is sens to work on the OMAP devices then read your 
thought "I'm not sure what exactly (other than tidiness) we gain from 
converting remaining non-QOM devices."

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Palmer Dabbelt]

On Tue, 06 Nov 2018 10:43:17 PST (-0800), Peter Maydell wrote:
> I had an idea for how to get a rough list of source files
> containing devices that haven't been QOMified. The theory
> is that a pre-QOM device generally has an "init" function
> which allocates memory for the device struct. So looking in
> hw/ for files which call g_new*() or g_malloc*() should get
> us all the non-QOM devices (as well as a pile of false
> positives, of course). The following link is the result of
> doing that and then eyeballing the results for false positives
> and throwing those out. It might have missed one or two
> files or included one or two by mistake. But I think it's
> pretty close, and it seems to have caught all the obvious
> ones I knew about. There are 61 files on this list.
>
> I am also suspicious about hw/bt/ but don't know enough
> about that subsystem to say if it could benefit from
> using QOM objects more.
>
> [...]
>
> hw/riscv/riscv_htif.c
> hw/riscv/sifive_uart.c

I poked around at it looks like both of these are valid targets for a QOM 
conversion, and I think the UART in particular would be meaningfully more 
useful with a conversion.  I'll add it to my TODO list, but I'm not sure how 
long it'll take to get around to it -- sorry!

Thanks for pointing this out!

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Mark Cave-Ayland]

On 06/11/2018 18:43, Peter Maydell wrote:

> I had an idea for how to get a rough list of source files
> containing devices that haven't been QOMified. The theory
> is that a pre-QOM device generally has an "init" function
> which allocates memory for the device struct. So looking in
> hw/ for files which call g_new*() or g_malloc*() should get
> us all the non-QOM devices (as well as a pile of false
> positives, of course). The following link is the result of
> doing that and then eyeballing the results for false positives
> and throwing those out. It might have missed one or two
> files or included one or two by mistake. But I think it's
> pretty close, and it seems to have caught all the obvious
> ones I knew about. There are 61 files on this list.
> 
> I am also suspicious about hw/bt/ but don't know enough
> about that subsystem to say if it could benefit from
> using QOM objects more.

> hw/ppc/prep.c

I had a quick look at this and AFAICT it's in the old -M prep code which is
deprecated and hopefully scheduled for removal soon, so I think we can leave this one.

> hw/sparc64/sparc64.c

This would appear to be from sparc64_cpu_devinit() which sets up a ResetData
structure like this:

    reset_info = g_malloc0(sizeof(ResetData));
    reset_info->cpu = cpu;
    reset_info->prom_addr = prom_addr;
    qemu_register_reset(main_cpu_reset, reset_info);

Presumably this can now be handled by using CPUClass's reset() method? The prom_addr
field is a per-machine parameter that is used to derive the starting PC for the CPU,
so I believe converting this to a qdev parameter on the SPARC CPU should suffice.


ATB,

Mark.

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

On 9 November 2018 at 10:17, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> On 06/11/2018 18:43, Peter Maydell wrote:
>
>> I had an idea for how to get a rough list of source files
>> containing devices that haven't been QOMified. The theory
>> is that a pre-QOM device generally has an "init" function
>> which allocates memory for the device struct. So looking in
>> hw/ for files which call g_new*() or g_malloc*() should get
>> us all the non-QOM devices (as well as a pile of false
>> positives, of course).

>> hw/sparc64/sparc64.c
>
> This would appear to be from sparc64_cpu_devinit() which sets up a ResetData
> structure like this:
>
>     reset_info = g_malloc0(sizeof(ResetData));
>     reset_info->cpu = cpu;
>     reset_info->prom_addr = prom_addr;
>     qemu_register_reset(main_cpu_reset, reset_info);

I think the code I saw that looked like a non-QOMified
device was cpu_timer_create().

The ResetData stuff is just working around the fact that
CPUs don't get reset unless the board code does something
to arrange for that to happen, so it's OK. (I would like
us to eventually tackle properly overhauling our approach
to reset, but that's a separate body of work.)

thanks
-- PMM

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Gerd Hoffmann]

  Hi,

> I am also suspicious about hw/bt/ but don't know enough
> about that subsystem to say if it could benefit from
> using QOM objects more.

I'm wondering whenever anyone would even notice if we just rm -rf hw/bt

Looking through the changelog for the last five years (after hw/ split)
the only thing I see is fixing warnings from compiler or coverity,
adapting to changes in other systems (chardev for example) and treewide
changes.  Not a *single* patch specific to bluetooth ...

cheers,
  Gerd

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Gerd Hoffmann]

On Fri, Nov 09, 2018 at 12:17:31PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > I am also suspicious about hw/bt/ but don't know enough
> > about that subsystem to say if it could benefit from
> > using QOM objects more.
> 
> I'm wondering whenever anyone would even notice if we just rm -rf hw/bt
> 
> Looking through the changelog for the last five years (after hw/ split)
> the only thing I see is fixing warnings from compiler or coverity,
> adapting to changes in other systems (chardev for example) and treewide
> changes.  Not a *single* patch specific to bluetooth ...

Tried this after studying docs:

  qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard

Segfaults right anway on first keypress.
I guess that qualifies as "broken and obviously unused".

cheers,
  Gerd

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Thomas Huth]

On 2018-11-09 12:29, Gerd Hoffmann wrote:
> On Fri, Nov 09, 2018 at 12:17:31PM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> I am also suspicious about hw/bt/ but don't know enough
>>> about that subsystem to say if it could benefit from
>>> using QOM objects more.
>>
>> I'm wondering whenever anyone would even notice if we just rm -rf hw/bt
>>
>> Looking through the changelog for the last five years (after hw/ split)
>> the only thing I see is fixing warnings from compiler or coverity,
>> adapting to changes in other systems (chardev for example) and treewide
>> changes.  Not a *single* patch specific to bluetooth ...
> 
> Tried this after studying docs:
> 
>   qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard
> 
> Segfaults right anway on first keypress.
> I guess that qualifies as "broken and obviously unused".

Thanks for checking! I guess that means we could even get rid of it
without deprecating it first if it is broken already for more than two
releases...?

 Thomas

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

On 9 November 2018 at 12:39, Thomas Huth <thuth@redhat.com> wrote:
> On 2018-11-09 12:29, Gerd Hoffmann wrote:
>> On Fri, Nov 09, 2018 at 12:17:31PM +0100, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>>> I am also suspicious about hw/bt/ but don't know enough
>>>> about that subsystem to say if it could benefit from
>>>> using QOM objects more.
>>>
>>> I'm wondering whenever anyone would even notice if we just rm -rf hw/bt
>>>
>>> Looking through the changelog for the last five years (after hw/ split)
>>> the only thing I see is fixing warnings from compiler or coverity,
>>> adapting to changes in other systems (chardev for example) and treewide
>>> changes.  Not a *single* patch specific to bluetooth ...
>>
>> Tried this after studying docs:
>>
>>   qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard
>>
>> Segfaults right anway on first keypress.
>> I guess that qualifies as "broken and obviously unused".
>
> Thanks for checking! I guess that means we could even get rid of it
> without deprecating it first if it is broken already for more than two
> releases...?

Maybe; but it's potentially a big feature and that's just
a test of one use case. I would be happier if we stuck
to our standard deprecation strategy. (We're not dumping
it in 3.1 so we have the easy opportunity to let our
users have at least one release of notice by putting in
a deprecation notice in for 3.1.)

thanks
-- PMM

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 09/11/2018 13:39, Thomas Huth wrote:
> On 2018-11-09 12:29, Gerd Hoffmann wrote:
>> On Fri, Nov 09, 2018 at 12:17:31PM +0100, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>>> I am also suspicious about hw/bt/ but don't know enough
>>>> about that subsystem to say if it could benefit from
>>>> using QOM objects more.
>>>
>>> I'm wondering whenever anyone would even notice if we just rm -rf hw/bt
>>>
>>> Looking through the changelog for the last five years (after hw/ split)
>>> the only thing I see is fixing warnings from compiler or coverity,
>>> adapting to changes in other systems (chardev for example) and treewide
>>> changes.  Not a *single* patch specific to bluetooth ...
>>
>> Tried this after studying docs:
>>
>>   qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard
>>
>> Segfaults right anway on first keypress.
>> I guess that qualifies as "broken and obviously unused".
> 
> Thanks for checking! I guess that means we could even get rid of it
> without deprecating it first if it is broken already for more than two
> releases...?

I think what others were using bluetooth passthrough.  But it's
certainly possible that it's broken.

Paolo

[Qemu-devel] deprecating/removing bluetooth (was: Re: List of files containing devices which have not been QOMified)

[Gerd Hoffmann]

On Fri, Nov 09, 2018 at 02:16:53PM +0100, Paolo Bonzini wrote:
> On 09/11/2018 13:39, Thomas Huth wrote:
> > On 2018-11-09 12:29, Gerd Hoffmann wrote:
> >>
> >> Tried this after studying docs:
> >>
> >>   qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard
> >>
> >> Segfaults right anway on first keypress.
> >> I guess that qualifies as "broken and obviously unused".
> > 
> > Thanks for checking! I guess that means we could even get rid of it
> > without deprecating it first if it is broken already for more than two
> > releases...?
> 
> I think what others were using bluetooth passthrough.  But it's
> certainly possible that it's broken.

That code is in bt-*.c (toplevel dir).  Likewise no actual code changes
since ages.  Comes in two variants, host + vhci.  vhci commit says:

    commit ab2b6f507ded382df734fe6a237ec56e2f421de4
    Author: balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
    Date:   Mon Sep 29 00:31:41 2008 +0000

        Use VHCI to allow the host os to participate in a qemu bluetooth "vlan".
    
        This does the reverse of bt-host.c, proxying from guest to host.
        Appears to be more reliable.

Hmm.  Not much of a clue.  Also ten years old.

There is also a null hci, not connecting to anything.  Probably useful as
dummy when your board has bluetooth (see arm/nseries) but you don't want
hook up any bluetooth devices.

Anyone has used bluetooth passthrough and can report what the state is?

I guess the keyboard can be dropped right away no matter what.

cheers,
  Gerd

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Mark Cave-Ayland]

On 09/11/2018 10:31, Peter Maydell wrote:

> On 9 November 2018 at 10:17, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> On 06/11/2018 18:43, Peter Maydell wrote:
>>
>>> I had an idea for how to get a rough list of source files
>>> containing devices that haven't been QOMified. The theory
>>> is that a pre-QOM device generally has an "init" function
>>> which allocates memory for the device struct. So looking in
>>> hw/ for files which call g_new*() or g_malloc*() should get
>>> us all the non-QOM devices (as well as a pile of false
>>> positives, of course).
> 
>>> hw/sparc64/sparc64.c
>>
>> This would appear to be from sparc64_cpu_devinit() which sets up a ResetData
>> structure like this:
>>
>>     reset_info = g_malloc0(sizeof(ResetData));
>>     reset_info->cpu = cpu;
>>     reset_info->prom_addr = prom_addr;
>>     qemu_register_reset(main_cpu_reset, reset_info);
> 
> I think the code I saw that looked like a non-QOMified
> device was cpu_timer_create().
> 
> The ResetData stuff is just working around the fact that
> CPUs don't get reset unless the board code does something
> to arrange for that to happen, so it's OK. (I would like
> us to eventually tackle properly overhauling our approach
> to reset, but that's a separate body of work.)

Ah okay. The above timers are certainly internal CPU timers rather than external, so
should they still be QOMified? How are timers modelled for other CPUs?


ATB,

Mark.

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Thomas Huth]

On 2018-11-09 14:16, Paolo Bonzini wrote:
> On 09/11/2018 13:39, Thomas Huth wrote:
>> On 2018-11-09 12:29, Gerd Hoffmann wrote:
>>> On Fri, Nov 09, 2018 at 12:17:31PM +0100, Gerd Hoffmann wrote:
>>>>   Hi,
>>>>
>>>>> I am also suspicious about hw/bt/ but don't know enough
>>>>> about that subsystem to say if it could benefit from
>>>>> using QOM objects more.
>>>>
>>>> I'm wondering whenever anyone would even notice if we just rm -rf hw/bt
>>>>
>>>> Looking through the changelog for the last five years (after hw/ split)
>>>> the only thing I see is fixing warnings from compiler or coverity,
>>>> adapting to changes in other systems (chardev for example) and treewide
>>>> changes.  Not a *single* patch specific to bluetooth ...
>>>
>>> Tried this after studying docs:
>>>
>>>   qemu -usb -device usb-bt-dongle -bt hci,vlan=0 -bt device:keyboard
>>>
>>> Segfaults right anway on first keypress.
>>> I guess that qualifies as "broken and obviously unused".
>>
>> Thanks for checking! I guess that means we could even get rid of it
>> without deprecating it first if it is broken already for more than two
>> releases...?
> 
> I think what others were using bluetooth passthrough.  But it's
> certainly possible that it's broken.

Since there haven't been any non-trivial changes to the files in
*years*, and apparently none of the current QEMU developers is
interested in maintaining this subsystem, I think it is really very
likely that it's broken. So unless someone has got some hardware that
could be used for testing it, I think we really should mark this as
deprecated - we could keep it in that state a little bit longer to see
whether a user speaks up and says that it is still useful, but in case
nobody uses this anymore, there is really no need that we carry this
code with us forever.

 Thomas

Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Peter Maydell]

On 10 November 2018 at 15:20, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> On 09/11/2018 10:31, Peter Maydell wrote:
>> I think the code I saw that looked like a non-QOMified
>> device was cpu_timer_create().

> Ah okay. The above timers are certainly internal CPU timers rather than external, so
> should they still be QOMified? How are timers modelled for other CPUs?

So, a couple of caveats first:
 * I haven't really looked at the sparc code
 * as I mentioned elsewhere in this thread, I'm not sure this is
   necessarily our most-important cleanup/refactoring

There are a couple of "QOM-style" ways I know of to do cpu timers:

(1) the Arm Cortex-A9/A15 have some timers that are part of the cpu
in the sense that they're always there in hardware, but they're just
memory-mapped devices at a known address. We model these as
the usual sort of standalone QOM device, with a convenience
container object in hw/cpu/ that instantiates the various devices
and wires things up.

(2) the newer Arm "generic timers" are more closely coupled to the
CPU, because they're programmed via system registers. These we
actually model as part of the CPU object itself, with the code all
in target/arm. The CPU object then exposes outbound GPIO lines
which are the interrupt signals for the timers, and which the board
or SoC code wires up to the interrupt controller.

So it depends on how closely coupled the sparc cpu timers are to
the cpu, I think.

thanks
-- PMM