On Wed, Nov 24, 2010 at 12:17:00PM -0600, Anthony Liguori wrote: > 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. > There are other examples. > >>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. > I think we disagree on what HW does. > >>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. PIIX3 may be totally implemented in FPGA code. I do not care. This is implementation detail. What important is that it provide the same functionality as ISA devices in the first IBM PC. That is why they are ISA devices and should be modeled as such. Otherwise you will have to redesign everything when you'll want to move to another chipset emulation that uses new and improved SuperIO-2XT technology inside. > > >>> 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. > I am glad we agree on that :) > >>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. -- 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
