Re: [Qemu-devel] CVS build error
Am 14.03.2008 um 00:32 schrieb Johannes Schindelin: On Thu, 13 Mar 2008, Rick Vernam wrote: [gcc4] Not supported? Okay, fine. But don't tell me it can't work. The fact of the matter is that I use it daily. Make configure fail horribly? Well, that seems a bit counter- productive, don't you think? If you would only have researched a _little_ bit, you would have found out that x86, by far the most common platform at the moment, which you should have known before stating what you stated, does _not_ work with gcc4. OK, so Rick is guilty not using the most common platform. Wasn't it one of the major goals of qemu to work on a wide variety of different platforms? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] don't die if switching to fullscreen mode fails
Am 26.02.2008 um 13:48 schrieb Andreas Winkelbauer: This patch changes the behaviour as follows: * deny switching to fullscreen mode if the resolution is too high and print a message to the console Very good idea. * use windowed mode as fallback option if we are already in fullscreen mode and the new resolution is too high and print a message to the console Do you end up with a window bigger than the screen, then? Is there a chance the user can escape from this situation, i.e. reach all parts of the virtual screen to find the switch for setting the resolution? Another option would be to simply display an Out of range error across the screen, like a real monitor would do. Usually, operations systems feature a protection against setting a resolution higher than supported by hardware already (set back to a lower reolution after some delay). Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] using actual PPC ROM?
Am 31.01.2008 um 16:41 schrieb C.W. Betts: is it possible to use an actual PowerPC ROM in qemu-system-ppc? This question pops up about once a month, so several people are interested in this. AFAIK, the current answer is: No, but patches are welcome. If not, why isn't it? It needs enthusiasm to debug something you have no sources or documentation for. Especially as an almost-working open source alternative exists. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: Even if another system starts working, if you break existing users, you did something wrong. And if you don't care, and don't mind giving existing users a hard time, you cannot be helped and should go somewhere else. So you have to be backwards oriented and willing to live with bugs to join your world. Good to know. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Am 19.01.2008 um 12:16 schrieb Johannes Schindelin: Hi, On Sat, 19 Jan 2008, Markus Hitter wrote: Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: Even if another system starts working, if you break existing users, you did something wrong. And if you don't care, and don't mind giving existing users a hard time, you cannot be helped and should go somewhere else. So you have to be backwards oriented and willing to live with bugs to join your world. Good to know. How dare you misrepresenting my words like that? Because for me it's what you essentially said. In search of a friendly agreement I'll continue off list. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Am 18.01.2008 um 19:10 schrieb Johannes Schindelin: But that broke a previously working system, and that's why I agree with Fabrice. At the same time it made a more modern system work. Refusing a patch because it exposes existing bugs isn't exactly intelligent. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 0/9] Intel Mac target support
Am 11.01.2008 um 13:26 schrieb Alexander Graf: On Jan 11, 2008, at 9:01 AM, Alexey Eremenko wrote: Alexander Graf: Thank you VERY much for providing us with intel mac emulation. I'm really having a hard time understanding if this is irony or not ;-). I don't think there's irony as qemu is the first emulator fit for Leopard[1], AFAIK. Markus [1] For non-Apple freaks: Leopard, that's Mac OS X v10.5, the most recent Macintosh OS. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
Am 05.01.2008 um 03:47 schrieb Rob Landley: You can disable overcommit and give the system an egregious amount of swap space, but then your pathological case is the system going into swap thrashing la-la land and essentially freezing (advancing at 0.1% of its normal rate, if that, for _hours_) instead of killing some runaway processes (or rebooting) and recovering. Quite obviously, we have very different expectations on what executables should do. I expect code to be as reliable as possible, to be careful when aquiring resources and if a process would ever happen to make my computer spontanuously reboot, I'd throw that binary as far away as possible and warn everybody else not to even touch this thing. One of the major reasons to run emulators is to protect against such sloppy code, btw. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] fix possible NULL pointer use in hw/ptimer.c
Am 03.01.2008 um 15:02 schrieb Paul Brook: Having to check every return value is extremely tedious and (as you've proved) easy to miss. Checking every return value is a measure for programming reliable code. If the allocation fails we don't have any viable alternatives, so we may as well stop right there. Stop != segfault? What about a meaningful exit message? What if the code doesn't segfault but runs havok? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Am 09.12.2007 um 17:52 schrieb Mike Kronenberg: On the other hand, the QT implementation is and remains the fastest solution, as no of the other allows directly accessing the video- buffer, which results in way more copying. Likely, QT doesn't come with it's own set of video drivers, but uses some core technology of OS X. It's obviously possible to get CoreGraphics to avoid single buffering, but it's hard to find documentation about this, since Apple obviously wants to avoid such hacks. Additionally, flushing the graphics buffer is limited to screen refresh rate, which makes performance comparisons difficult: http:// developer.apple.com/documentation/Performance/Conceptual/Drawing/ Articles/FlushingContent.html#//apple_ref/doc/uid/TP40001835 At last, there is sample code which shows how to get pixels onto the screen without using the CPU at all: http://developer.apple.com/ samplecode/TextureRange/index.html HTH, Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] Make Cocoa use CoreGraphics
Am 08.12.2007 um 01:18 schrieb Alexander Graf: Please review [...] qemu-cocoa.patch This override of initWithFrame: appears to be obsolete: [EMAIL PROTECTED] QemuView +- (id) initWithFrame: (NSRect) frameRect +{ +self = [super initWithFrame: frameRect]; [...] +return self; +} Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH] OSX x86_64 host support
Am 07.12.2007 um 18:43 schrieb Pierre d'Herbemont: This is the QuickDraw API? If so, it should be quite straight forward to use OpenGL or CoreGraphics instead... There is prior art (to get isnpired) in BasiliskII. From it's file src/MacOSX/video_macosx.h: // Using Core Graphics is fastest when rendering 32bit data. // Using CGImageRefs allows us to use all the bitmaps that BasiliskII supports. // When both Basilisk II and OS X are set to 'Thousands', updating a 312x342 // window happens at over 500fps under 10.2, and over 600fps on 10.3! Basilisk's sources are here: http://gwenole.beauchesne.info/projects/basilisk2/files/ BasiliskII_src_01052006.tar.bz2 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Am 03.12.2007 um 11:30 schrieb Laurent Vivier: But if you think I should remove the buffered case, I can. In doubt, less code is always better. For the unlikely case you broke something badly, there's always the option to take back the patch. BTW, do you think I should enable cache=off by default ? This would be fine for a transition phase, but likely, the cache=on case gets forgotten to be removed later. So, do it now. my $ 0.02, Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 1/3] Add args to -cdrom to define where is connected the cdrom
Am 29.10.2007 um 15:07 schrieb [EMAIL PROTECTED]: On Mon, Oct 29, 2007 at 03:02:21PM +0100, Laurent Vivier wrote: Daniel P. Berrange a écrit : I'd suggest that we leave all the -hda,hdb,hdc,-cdrom,-fda,-fdb etc unchanged and use the -disk for setting up all types of disks, floppys, cdroms, etc. It would just require one extra field for the -disk arg: -disk file[,if=type][,bus=n][,unit=m][,mode=mode] where type defines the interface. [ide,scsi,fd] (by default, ide) n defines the bus number (by default 1) m defines the unit number (by default 0) mode defines one of [disk,floppy,cdrom] I agree with that. And if everyone agrees I can modify patches to do that... Laurent not to be rude, but my version of the scsi patch supports three controllers, for a total of 21 disks. might i reccomend you impliment -disk with a controller, bus, target syntax, ALA sun? Would it be possible to use isa's bus number to describe an scsi controller? If you have controllers with two buses, talk to them like two distinct controllers. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] Re: [kvm-devel] [PATCH][RFC] Allowing QEMU to directly execute a directory (and storing command line options in it)
Am 31.08.2007 um 20:54 schrieb Anthony Liguori: It makes little sense to pass a directory when you can pass a config file and assume that the directory the config file is in is the CWD. In fact, most people having designed bundle-type document formats came to a different conclusion: http://en.wikipedia.org/wiki/Bundle_ (NEXTSTEP). Typically, bundles are opaque and appear like a single file to the desktop user. [...] And then do: qemu -c MyImage/vm.cfg In opposite to qemu -c MyImage ? Why do you want the user to do extra typing? There's one config in one directory, so typing the config file name is just redundant. To me, Jorge's implementation looks just fine. + usage: %s [options] [disk_image|folder]\n usage: %s [options] [diskimage | bundle]\n ^^ Go ahead an call the baby by it's name? m$0.02 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone
Am 30.07.2007 um 22:37 schrieb Andreas Färber: Maybe someone can shed some more light on what exactly needs to be changed config-wise or is missing in OpenBIOS or qemu in order to boot AIX 6 or any Linux. Can't tell you much, but for sure, you won't need support for HFS or HFS+. HFS support enables you to boot all versions of classic Mac OS (1.0 to 9.2.2). HFS+ can be used for Mac OS 8.1 and later. Mac OS X can boot off HFS+ and off UFS. All PPC Macintosh OSs use an Apple partition map. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] Emulation: Building solid files
Am 27.06.2007 um 00:22 schrieb NetAudi: Building virtual machines taking only one big binary file (merging Qemu engine and HD image file). It could be good for future portable aplications. I thought this because I'm triying to do the simplest-ultra-secure Internet navigatior. The idea is to generate a VM (with the lightest/ functional O.S. posibility and increase speed at top) to content a Firefox installation (with the most used complements into it). The main is to load all this VM into the RAM and when it will turn off, it never has to save the session changes, it allways must start at the beginning point. How does stuffing all virtual machine parts into one file help you to load a virtual machine entirely into RAM? Surely, one could manage to load multiple files into RAM. Additionally, I don't see how it helps security if you move the hard disk for the virtual machine into RAM. It should be fully sufficient to let the inital hard disk sitting in the file system and to record changes to the virtual hard disk, only. qemu supports such recordings (shadowed file systems) already and if it makes you happy, it shouldn't be too hard to keep the record of changes in RAM. This saves you a lot of startup time as well als hundreds of megabytes of RAM. For an approach without any changes to qemu, you could have a look into how (Linux) Live CDs work. Most of them work without a writeable hard disk, managing all the RAM-disk stuff themselves. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Qemu-devel] Classic Mac OS
Hello all Somewhere in the FAQs, the state of Classic Mac OS ist mentioned as it is being worked on. Is this still true, is it possible to join the effort? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/