Re: [Qemu-devel] [patch] TOC support for raw cdrom block devices
On 10/24/06, Josh Elsasser <[EMAIL PROTECTED]> wrote: The current raw block drvice code fakes a TOC with one track covering the entire disc. With this patch it attempts to read the TOC from a cdrom device and make that information available to the ide driver when the guest issues an ATAPI READ TOC/PMA/ATIP type 0 (read TOC) command. I recently sent a patch to add this for linux but then I thought of a better way to do it. I the TOC was stored in a struct somewhere, built when starting (or changing media) using either .toc, .cue, real CD or maybe even a list of track files this would allow to use such methods. Would be really useful for me actually to be able to use a list of tracks but generating toc/cue is quite easy. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
> Oh, c'mon, Rob! I really didn't want to ask Paul Brook that, but > sure you'll fix my cluelessness right here, right now - tell me, tell me, > why Linux has dynamic-loadable modules support, which clueless passers-by > like me call "plugins"? It must be closed-source diversion, no? Linux has genuine reasons for wanting modules. Kernel size is important because (a) it has to be loaded by the bootloader, often from a small, slow device (eg. floppy, flash or network). (b) The whole kernel is permanently locked into ram. It you've ever tried to build a kernel with everything enable you'll know the result is unreasonably large. Modules allow the same kernel to work on a wide variety of large and small machines. It's also a fairly convenient way of allowing userspace to disable a particular set of drivers. Closed source kernel modules are explicitly *not* supported by kernel developers. A typical qemu process already uses well over a hundred Mb of memory. Saving a few hundred k of code at runtime isn't going to make any difference to anything. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [patch] TOC support for raw cdrom block devices
On Wed, Oct 25, 2006 at 01:47:00PM +0200, Pascal Terjan wrote: > I recently sent a patch to add this for linux but then I thought of a > better way to do it. > I the TOC was stored in a struct somewhere, built when starting (or > changing media) using either .toc, .cue, real CD or maybe even a list > of track files this would allow to use such methods. Would be really > useful for me actually to be able to use a list of tracks but > generating toc/cue is quite easy. That would probably be better than reading the TOC from the CD each time the guest requests it. I had thought of using a .toc or .cue file as well, however it wasn't required for my purposes. -jre pgpNaXIg5ThIV.pgp Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-arm translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook 06/10/25 17:43:33 Modified files: target-arm : translate.c Log message: Fix ARM VFP debugging dumps. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.43&r2=1.44 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
On Wednesday 27 September 2006 4:27 am, Martin Guy wrote: > There are some statistics at freaknet.org/martin/QEMU for various > types of x86 processor, but giving only BogoMIPS, which are way > overrated. > I presume this is cos QEMU translates the kernel speed test loop once > then runs it as x86 code, while "real" tasks need to be translated all > the time. There is a cache of translated pages, and last I checked (0.8.0 or so) the entire translation cache was flushed when it filled up, rather than trying to do any kind of LRU-style thing. I think of qemu as a processor with a bigger than normal penalty for faulting executable pages from DRAM into L2. :) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vs gcc4
On Tuesday 24 October 2006 8:24 pm, Paul Brook wrote: > ColdFire is the only target that uses it exclusively. Arm is currently a > hybrid of dyngen and the new backend. So is i386, to a lesser extent. > Other targets have minimal changes necessary to make them work. Ok. > > Do you have a quick "here's you how try it out" thing? (For example, when > > I first show people qemu I boot a knoppix cd image under it. Fast and > > shiny. :) > > One of my goals when writing it was to be able to reuse most of the existing > qemu code. There should be no user-visible impact. Unless you already > understand how qemu/dyngen works it's not going to mean a lot to you. I read Fabrice's presentation, and looked through the code a bit, but "understand" is _way_ too strong a word. :) > The end result is very similar, just a slightly different strategy for > getting there. A strategy that might work with gcc 4.x? :) > In theory it should allow better performance, but that's still a way off. I was poking at the tcc code to generate stuff and optimize a couple weeks ago. I don't suppose there's any possible re-use between the two? > https://nowt.dyndns.org/ has patches against cvs (thought they may be > slightly out of date), and a complete svn repository you can checkout. Build > it just like normal qemu. Which in my case means applying the patch to get it to build with gcc 4.x, which does indeed apply without rejects to your svn repository. Unfortunately, the result doesn't build: gcc -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/home/landley/qemu/nowt.dyndns.org/qemu/target-sparc -I/home/landley/qemu/nowt.dyndns.org/qemu -I/home/landley/qemu/nowt.dyndns.org/qemu/host-i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/landley/qemu/nowt.dyndns.org/qemu/fpu -I/home/landley/qemu/nowt.dyndns.org/qemu/slirp -c -o tcx.o /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c: In function ‘tcx_draw_line32’: /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c:94: error: invalid lvalue in increment /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c: In function ‘tcx_draw_line16’: /home/landley/qemu/nowt.dyndns.org/qemu/hw/tcx.c:106: error: invalid lvalue in increment make[1]: *** [tcx.o] Error 1 make[1]: Leaving directory `/home/landley/qemu/nowt.dyndns.org/qemu/sparc-softmmu' make: *** [subdir-sparc-softmmu] Error 2 I don't have gcc 3.x installed on my laptop. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Config file support
Hi, On Tue, 24 Oct 2006, Rob Landley wrote: > On Tuesday 24 October 2006 6:47 am, Flavio Visentin wrote: > > At this point it's really cleaner and maybe simpler to use XML > > Have you ever implemented a validating XML parser? I have. It only > _looks_ "clean and simple". +1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
