qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/19] hw/ directory restructuring
Date: Tue, 05 Feb 2013 07:19:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 04/02/2013 22:23, Peter Maydell ha scritto:
> 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 :-)

hw/misc be it then. :)

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

I think in that case what we want is to use composition to make the
machine model code as small as possible.  And then leave the little bits
of glue code that remain in hw/$TARGET (or target-$TARGET/boards).

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

Ok.

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

Yes.

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

Because arm_gic.c was already in hw/arm/Makefile.objs, while
hw/heathrow_pic.c was in hw/Makefile.objs.  This certainly can be refined.

Thanks for the useful ideas!

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]