Am 29.06.2017 um 03:02 schrieb Philippe Mathieu-Daudé: > There have been some comments on the ML about the usefulness of tci. > > https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04551.html > > Peter Maydell> I'd prefer we just got rid of it. > > https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04296.html > > Richard Henderson> Is it time to remove it? I'm pretty sure the only hosts > for which it will work have proper backends... > > Richard quotes are way clearer than me trying to paraphrase what he told me: > - it doesn't use libffi, and as such the way it makes calls to helpers > doesn't work for many hosts. > - we already cover almost everthing that debian does. if debian or gentoo > doesn't support it, one can confidently say there's little interest. > - if someone *does* want to run qemu on something else, it isn't difficult to > port tcg. > > I figured out MAINTAINERS was unsync, so added patches 1-4, they are not > really > tci-related. > > Patches 5,6 are trivial fixes to let the codebase quite sane if there is > future > need to revert/reimport tci. > > Patches 7,8 are the removal, marked RFC... let's debate! > > Regards, > > Phil.
Hi, as Peter already has written, there are different perspectives on QEMU. My conclusion is that depending on those perspectives people come to different results whether certain code parts are useful or not. When I started using (and contributing) to QEMU in 2006, I wanted to analyse code running on an embedded MIPS system. With real hardware that was impossible, but with QEMU I could watch and debug that code (as soon as the MIPS emulation was sufficiently good, so that was my initial motivation). Later I was responsible for automated software tests. Those tests included software written for embedded PCs. The only missing components for an emulation with QEMU were the network cards, so I wrote the eepro100 (part of official QEMU) and dp8381x (only in my fork) network hardware emulations. Later I wanted to build and run QEMU on platforms which were not implemented. So that was the motivation to write TCI. I also used TCI to analyse TCG commands with Valgrind. It is for example very easy to count the frequency of the different TCG opcodes executed in an emulation run. TCI could also be used to monitor register usage with minimal code changes. And I still think that it is the easiest way to build QEMU on a completely new platform (that should work out of the box) and to make emulation work there (that might require some efforts). In my current role I'm interested in the emulation of old computer systems. Therefore my fork still includes some hardware emulations which were removed in the official QEMU, and especially emulation of all generations of the Intel PC platform is important for me. I am aware that neither of those applications is in the primary focus of most QEMU developers who want to have a stable, well performing platform for server virtualisation. My server qemu.weilnetz.de also uses that technology, so I want that, too. Nevertheless QEMU is the only software which I know which not only addresses the needs for server / PC virtualisation, but also is useful for researchers and scientists, archivists, learners and teachers or experimenters. Up to now, I had the impression that QEMU is sufficiently modular so that the different perspectives and expectations could be supported without harming each other too much. The only drawback was additional code (which would not be needed when focussing on a single perspective) causing additional compilation time and more (formal, mostly automated) file changes for code clean ups and API changes. Cheers Stefan