[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM |
Date: |
Thu, 15 Sep 2011 14:54:36 +0100 |
On 15 September 2011 14:35, Paolo Bonzini <address@hidden> wrote:
> It still holds, for two reasons. 1) The properties will be named
> differently for ISA and PCI versions, which is at the very least ugly; 2) if
> you want to save the property names for the ISA version, you need to
> duplicate the logic in NE2000 and PCI_NE2000.
>
> If we had C++ and templates, the problem would be much less pressing: just
> use inheritance for PCI and template for ISA vs. PCI. The code duplication
> at least is invisible to the programmer, it's only in the object files.
Personally I think the right way to approach this sort of thing is going
to be to have some sort of special purpose language for declaring
devices (and their composition, wiring, interfaces, properties) which is
used to generate all the tedious boilerplate code. Actual interesting code
(corresponding roughly to "method bodies") stays as C functions in
standard C source files.
It's already the case with existing qdev that just instantiating and
setting the properties for a qdev device is sufficiently tedious
that we have lots of utility foo_create() functions scattered around
the codebase. I don't think QOM is going to be any better there.
More generally, I don't think we should let our conceptual model of
how devices are composed and connected be warped by whether you can
implement it with C-and-a-pile-of-macros or not.
-- PMM
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, (continued)
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gleb Natapov, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gleb Natapov, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Edgar E. Iglesias, 2011/09/16
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM,
Peter Maydell <=
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Peter Maydell, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paolo Bonzini, 2011/09/15
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/09/15
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/09/15
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/09/18
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/09/18
Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Gerd Hoffmann, 2011/09/16