On 11/24/2010 11:33 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
Why deny this flexibility from those who need it for modelling
different HW? Besides, as I said, PIIX3 is ISA bridge and this
is what class should implement. We have fw_cfg on ISA bus too
which does not exits on real HW and we may want to have other
devices. We should be able to add them without changing PIIX3
class.
Because this flexibility is a misfeature. It's something that noone
actually uses and I've never seen anyone ask to have.
It introduces a PC-centric view of the world where you artificially
make a bunch of devices have bus specific logic that they really
don't have.
Actually other way around. Non PC embedded systems are those that needs
this flexibility the most.
If you want to go down this route, the right approach to take is to
make a separate IsaMc161818a device that has a Mc16818a device with
a has-a relation (i.e. composition).
There are many devices in qemu that accessed via isa bus on PCI and via
MMIO in other archs, so the thing you propose here is logical and
actually implemented this way in qdev.
Except the Mc16818a device is not a qdev device.
But I don't see the point. Just stick the Mc16818a device in the
PIIX3 via composition as it exists on normal hardware and call it a
day.
Shortcuts, shortcuts. I think this is how qemu was written initially.
"Lets put this here and call it a day!"
Implementing something correctly in the way that hardware does is not a
short cut.
Right, and real HW does composition in the PIIX3 device. So let's
not regret making everything an ISA device later.
You design by packaging not functionality?
No, if you want the ability to remove devices from the PIIX3, fine, but
don't call them ISA devices just for the sake of it.
Garbage collection can be done
while vcpu executes guest code and in proper implementation vcpu thread
should execute device model code for a very brief time and do not sleep
there. All this makes me think that garbage collection shouldn't be a
big issue for kvm userspace.
But I don't see the point. If you look at my repository, there's
The point is that C++ is ugly language. The short code Avi sent remind
me perl (aka line noise). It is almost impossible to parse it into
what code it actually does. Most symbols are there for C++ syntax not
functionality.
I'm using C++ to understand how to make a correct design model. The C++
part is only 10% of what I care about.
I agree that Avi's example is not a strong justification for C++ and I
also agree that it's uglier than the same implementation in C.
very few memory allocations. This is largely due to the fact that I
don't overly abstract busses and rely on simple composition where
appropriate.
I am not sure you can write useful program with few memory allocations.
Ultimately, you're allocating the same amount of memory, but in fewer
steps (because of static composition).
Regards,
Anthony Liguori
Plus, with tr1::smart_pointers, you can be leak free without every
worrying about explicit freeing. There are, of course,
possibilities of having circular references but it's not too hard to
avoid that in practice.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
