Re: [Qemu-devel] CVS build error

2008-03-14 Thread Markus Hitter


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

2008-02-26 Thread Markus Hitter


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?

2008-01-31 Thread Markus Hitter


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

2008-01-19 Thread Markus Hitter


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

2008-01-19 Thread Markus Hitter


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

2008-01-18 Thread Markus Hitter


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

2008-01-11 Thread Markus Hitter


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

2008-01-05 Thread Markus Hitter


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

2008-01-04 Thread Markus Hitter


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

2007-12-11 Thread Markus Hitter


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

2007-12-07 Thread Markus Hitter


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

2007-12-07 Thread Markus Hitter


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

2007-12-03 Thread Markus Hitter


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

2007-10-29 Thread Markus Hitter


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)

2007-09-01 Thread Markus Hitter


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

2007-08-02 Thread Markus Hitter


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

2007-06-27 Thread Markus Hitter


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

2007-05-21 Thread Markus Hitter


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/