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

[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 :-)

> 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.

Why should you care which machine models happen to have particular
CPUs? In future we may even have machine models which have two CPUs
of different architectures...

>>> 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.

(This is a bit of a tangent, but
As I understand it, if it's really a driver it should be moving.
>From https://lwn.net/Articles/443510/:
"There will of course need to be at least some ARM-specific code
[in arch/arm], but the end goal is for that code to be limited to
ARM core architecture code and ARM SoC core architecture code.
Furthermore, the ARM SoC core architecture code should consist
primarily of small plugins for core-Linux-kernel frameworks".
arch/arm64 won't have mach-* subdirs at all, we are stomping on
that before it starts :-)

By analogy with this, anything we have which is a self-contained
device should definitely not be in hw/$TARGET. Small bits of code
like arm_boot.c, OK (and perhaps machine models, though I'm
dubious there because I'd like to see us moving to a framework
where machine models are just another kind of device). But if
it's really a device and we've been able to model it as a qdev
device then it shouldn't be 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).

I could live with a rule that says "no devices in hw/$TARGET unless
they're there for legacy reasons because they share a source file
with a machine model" [and ideally eventually pull any self-contained
devices out of those files]. That's a nice clear line for reviewing
new patches.

Why, for example, is arm_gic.c moved to hw/arm but hw/heathrow_pic.c
moved to hw/misc rather than hw/ppc ?

-- PMM