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

[Paolo Bonzini]

Il 04/02/2013 21:33, Peter Maydell ha scritto:
> On 4 February 2013 18:59, Paolo Bonzini <address@hidden> wrote:
>> Il 04/02/2013 19:13, Peter Maydell ha scritto:
>>> I think this is inconsistent. Either we should organise by category,
>>> or we should organise per-target, but we shouldn't try to do both.
>>> Otherwise we're just going to wind up with half the $TARGET-specific
>>> $FOO device models in hw/$TARGET and the other half in hw/$FOO.
>>
>> 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.

The final submission may not have an hw/misc at all, the odd device like
tmp105.c can go in hw/i2c.

> (Also a hw/machines might be a good idea.)

I don't like it very much because it's not clear which targets are used
for which machines.  I want to move away from the hw/arm/../foo.o hack
that is used now.

>> or are always target-specific, and
>> hw/$TARGET has them.
>>
>> Also, the kernel similarly has arch/$TARGET and drivers/$FOO.
> 
> Yes, and the ARM kernel maintainers have just spent quite a lot
> of effort in cleaning things up to kick all the drivers out
> of arch/$TARGET and into drivers/$FOO where they belong.
> I'd rather we didn't get into that mess in the first place :-)

Yes, and in fact I'm moving a lot of ARM devices away from hw/arm's
Makefile.objs to other directories (net/ for NICs, char/ for UARTs
etc.), and configuring them via default-configs/arm-softmmu.mak.

But Linux still has a bunch of board-specific drivers in arch/arm/mach-*
that won't be moved to drivers/, and that's roughly what I left in
hw/$TARGET.

(Note: some boards still have devices in hw/arm after these patches,
e.g. musicpal has a NIC and LCD controller.  Those could indeed be
refactored to other directories.  However, this series is not splitting
files, only moving them.  The purpose is to get out of the local optimum
we're stuck in).

Paolo