Re: [Qemu-devel] [PATCH 00/19] hw/ directory restructuring

[Paolo Bonzini]

Il 05/02/2013 12:06, Andreas Färber ha scritto:
> Am 04.02.2013 22:23, schrieb Peter Maydell:
>> On 4 February 2013 20:51, Paolo Bonzini <address@hidden> wrote:
>>> Il 04/02/2013 21:33, Peter Maydell ha scritto:
>>>>> The $FOO device models should all be in hw/$FOO.  But there are some
>>>>> parts that do not fit in a category
>>>>
>>>> Surely this is what hw/misc is for?
>>>
>>> It's mostly interrupt/GPIO/DMA/memory/cache controllers.  I placed some
>>> of them are in hw/misc because they are in common-obj-y, but I don't
>>> like the idea of hw/misc very much.  hw/misc is really for the one-offs
>>> such as the tmp105.c temperature controller.
>>>
>>> If you prefer with creating a bunch of hw/ subdirectories like hw/pic,
>>> hw/gpio, hw/dma I can certainly move more stuff out of hw/$TARGET.  As
>>> long as there is consensus, it's fine.  But I wanted to avoid
>>> proliferation of hw/$FOO directories having only 5-10 files.
>>
>> I don't care if devices go in hw/misc or hw/extremely-fine-grained-category
>> as long as they don't go in hw/$TARGET :-)
> 
> So where would you like a tegra2.c SoC device/object to live?
> It depends on ARMCPU and is thus fo me a clear candidate for hw/arm/,
> among boards such as ac100.c, kaen.c, ...

I think we agree that almost all of it would be in hw/i2c/tegra2_i2c.c,
hw/sd/tegra2_sd.c, hw/misc/tegra2_whatever.c.  If you need a device just
because you're developing it with QOM composition, then the device could
go in hw/arm/tegra2.c together with the board description.  As they say,
the exception that confirms the rule.

> And this is not just a question of directory locations: If Tegra2 I2C is
> supposed to go to hw/i2c/ then it shouldn't use a hw/tegra2.h or
> hw/arm/tegra2.h header but should have its own hw/i2c/tegra_i2c.h
> header, which is beyond the scope of a touch-all file movement and
> should definitely not be done in one huge patch.

I agree on both aspects.  But for existing boards, I prefer to move all
C files and keep the big header files.

> If it takes 120 patches, then we can do it in chunks, but we can't just
> give up review of such refactoring series for the goal of doing
> something quickly.

Yes, we can do it in chunks, but we have to agree in advance with the
result.  Also, we cannot do it in too small chunks, because these series
are very expensive to maintain.  I think moving all purely-device files
to hw/CATEGORY/, and all board files to hw/ARCH/ is a good first step.
Among other things it sets a good precedent for the next ports that are
contributed ("no new hw/*.c files").

Splitting headers can come later, together with any QOMification.  There
is also no urgency to move from common-obj-y to obj-y.  Basically up to
patch 16 in this series.

> There's no urgent need to split up the directory
> (file system / git limits or the like), so we shouldn't sacrifice being
> able to actually work on particular devices in a meaningful way.

What constitutes a non-meaningful way in your opinion?

> Doing this sensibly would also help the NEED_CPU_H patch. QOM'ifying
> devices more before moving them can help reduce the amount of headers
> needed (or their interdependency), for instance.

Yes, consider that part delayed indefinitely. :)

Paolo