From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjvdF-0003WU-PX for qemu-devel@nongnu.org; Thu, 21 Jul 2011 11:57:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjvdB-0003Wt-PF for qemu-devel@nongnu.org; Thu, 21 Jul 2011 11:57:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjvdB-0003Vk-Hq for qemu-devel@nongnu.org; Thu, 21 Jul 2011 11:57:45 -0400 Message-ID: <4E284C74.2010708@redhat.com> Date: Thu, 21 Jul 2011 18:57:40 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E259F6E.8000204@us.ibm.com> <4E2824D2.2050401@redhat.com> <4E2827A2.6010603@us.ibm.com> <4E282BE3.1050404@redhat.com> <4E283C90.8010806@us.ibm.com> <4E283FFE.6090201@redhat.com> <4E28497C.5010801@us.ibm.com> In-Reply-To: <4E28497C.5010801@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] QEMU Object Model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel , Markus Armbruster On 07/21/2011 06:45 PM, Anthony Liguori wrote: >>> See git://git.codemonkey.ws/kvm++.git >>> >> >> Connection refused.. > > > Sorry, stupid EC2. Try http://git.codemonkey.ws/git/kvm++.git You don't have permission to access /git/kvm++.git/ on this server. > > >>> It's exactly the same object model, but in C++. Some things are nicer, >>> some things are not nicer. It's not quite a slam dunk. >>> >>> But what really concerned me about it was that I quickly realized that >>> it was going to be mostly write-only code. The C++ tricks that you >>> need to do to make it all work well are extremely obscure. It requires >>> template meta-programming, every obscure detail about partial >>> specialization, etc. >> >> Yes, that's a big worry. Is all of that exposed to the implementer? Or >> just in the framework? > > I was able to get it mostly hidden but not entirely. The biggest > problem is that even with a semi normal looking function, a simple > mistake like passing in the wrong number of arguments can result in an > undecipherable error message. It's not bad to debug if you're used to > it but very difficult to just slip in to a C project. I have to agree with this. You can write neat domain specific languages in C++ but the nice abstractions break the minute you misplace a comma. > >>>> >>>> There is quite a lot of boilerplate - around half the code of >>>> tcp.[ch]. >>>> It may be simple to create a new type to the author of the framework, >>>> but I doubt it would be simple to others. There would be a lot of >>>> cut'n'paste. >>> >>> Yup. That's the price you pay for using C over C++. But the ratio is >>> only true for simple types. Complex types (look at chrdrv.h), the >>> ratio is much lower. >> >> chrdrv.c is almost 100% boilerplate. > > Sure, but so is qemu-char.c and block.c. It's not really different > from what we have today. I'm trying to get us away from boilerplate, actually writing the code that matters? Maybe it's an unsolvable problem. With a low level language, you get to write boilerplate. With a high level language, the compiler writes it for you, and a whole lot more you don't want. But it's a big problem. Those conversions suck the life force out of whoever's doing them, and then he comes back as zombie to haunt us at the next kvm forum. It's not just type safety at stake here. >> The big problem with this plan is that steps 2 and 4 are very difficult >> and yet we see no gains while it's being done. > > So at least with the chardev conversion, we'll get the ability to > dynamically add character devices and change the settings of a chardev > after start up. Both of these are important features. > > I think done properly, it all can have incremental value. I worry > about converting the device model. > >> A much smaller job (the >> memory API conversion) is turning out to be no fun at all. > > Yeah, I don't know how to fix that. This is why I'm starting with the > backends. They're much smaller than the device model. Ok. Let's hope you've hit on the least-bad tradeoff. I'm sceptical, but I don't have anything concrete to offer. >>> I don't ever see the device model being written in something other >>> than C/C++ too. Having a GC in the VCPU thread would be a major issue >>> IMHO. >> >> We get the equivalent of GC every time a vcpu thread is scheduled out so >> an iothread or an unrelated process can run. > > But you can control this with pinning, priorities, etc. You cannot > with GC. > > And in quite a lot of systems, GC pauses are very, very long. I expect the number of objects we'll have will be very small (O(info qdm | wc -l)). They'll also be very long lived. Won't that make the GC rather fast? > >> It will hurt hard realtime >> guests, but these are only interesting to a small subset of users. >> >> I think that if we can get the data path to run in pure C, and have the >> GC HLL involved only when the device model is reconfigured, then we have >> an acceptable tradeoff. I don't claim that I know how to do this, >> though. This is a really hard problem, mostly due to the huge size of >> qemu. > > This is one very good thing about having a common object model that's > pluggable (which is what QOM is all about). It becomes relatively > easy to build with CONFIG_PCI=n, then build a shared library that > implements a new PCI layer in your favorite HLL so that you can > experiment. If I wanted a new PCI layer I'd write one outside of qemu. Getting PC emulation is probably easier than converting all of qemu - see tools/kvm (though they're not doing full emulation, just the subset needed to get Linux going). I want the old layer, it has a lot of knowledge sweated into it and it's very compatible with itself and with the guests it has booted. -- error compiling committee.c: too many arguments to function