Hi,
2008/2/5, Fabrice Bellard <[EMAIL PROTECTED]>:
> This is an SDL related issue (i.e. SDL may or may not use OpenGL to
> display graphics). Fixing SDL for Mac OS X would also be interesting.
I think SDL trunk (1.3) supports OpenGL rendering more specifically
for various platforms.
Besides, on
On Wednesday 06 February 2008, Jamie Lokier wrote:
> Paul Brook wrote:
> > > > but make
> > > > it configurable on the command line. That way, there are no
> > > > surprises ever. The rare people like me with an issue can just pass
> > > > a command-line parameter in.
> > >
> > > The point I was
Paul Brook wrote:
> > > but make
> > > it configurable on the command line. That way, there are no surprises
> > > ever. The rare people like me with an issue can just pass a command-line
> > > parameter in.
> >
> > The point I was trying to make is that qemu could easily arbitrate the
> > guest
On Tuesday 05 February 2008 15:07:27 H. Peter Anvin wrote:
> Rob Landley wrote:
> > When running a 2.6.24 kernel built for x86-64 under qemu via serial
> > console, doing CPU-intensive things that also produce a lot of output
> > (such as compiling software) tends to produce the error message in th
On Tue, 5 Feb 2008, Jernej Simončič wrote:
On Tuesday, February 5, 2008, 22:34:04, Asheesh Laroia wrote:
I agree with this - guesswork and invisible options can be confusing.
That's why I suggest what I think is the simplest solution: Just let
this be overridable on the command line.
Isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Jackson wrote:
> So while this setup is being made configurable, I think it would
> probably be best for qemu's range to be changed to a random range.
The customizable subnet is obviously the preferred choice, but if I had to
choose a subnet I'd c
On Tuesday, February 5, 2008, 22:34:04, Asheesh Laroia wrote:
> I agree with this - guesswork and invisible options can be confusing.
> That's why I suggest what I think is the simplest solution: Just let this
> be overridable on the command line.
Isn't the user-net IP irrelevant to the outside?
On Tue, 5 Feb 2008, Paul Brook wrote:
but make it configurable on the command line. That way, there are no
surprises ever. The rare people like me with an issue can just pass a
command-line parameter in.
The point I was trying to make is that qemu could easily arbitrate the
guest network b
> > but make
> > it configurable on the command line. That way, there are no surprises
> > ever. The rare people like me with an issue can just pass a command-line
> > parameter in.
>
> The point I was trying to make is that qemu could easily arbitrate the
> guest network based on how the host is
Asheesh Laroia <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008, Ben Taylor wrote:
>
> > It seems to me that there is a corner case where the local host has a
> > 10.0.2.x or 10.0.x.x address which would cause a qemu guest problems
> > that has a 10.0.2.15 address (for -net user only).
>
I think in VBox the Slirp IP address can be changed. I didn't take
that part to my patch:
http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html
but it should be easy to add.
Currently all NICs share the same subnet.
On 05/02/2008, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not
> 10.0.2.x"):
> > Samuel Thibault <[EMAIL PROTECTED]> writes:
> > > Mmm, actually, shouldn't qemu use a more "private" network like a
> > > RFC1918 172.16.0.0/12 network?
>
On Tue, 5 Feb 2008, Ben Taylor wrote:
It seems to me that there is a corner case where the local host has a
10.0.2.x or 10.0.x.x address which would cause a qemu guest problems
that has a 10.0.2.15 address (for -net user only).
That's right - that's the issue that I faced.
I think the defau
Warner Losh <[EMAIL PROTECTED]> wrote:
> From: Andreas Färber <[EMAIL PROTECTED]>
> Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
> Date: Tue, 5 Feb 2008 13:58:28 +0100
>
> >
> > Am 05.02.2008 um 12:30 schrieb Ian Jackson:
> >
> > > I don't believe that 10.0.2.0/24 was c
Anthony Liguori wrote:
Johannes Schindelin wrote:
Hi,
On Tue, 5 Feb 2008, Anthony Liguori wrote:
I would really like to use OpenGL on non-Apple platforms. OpenGL
gives much better scaling than SDL. Typically, and OpenGL app has
very little platform specific code. It would be nice if we
Johannes Schindelin wrote:
Hi,
On Tue, 5 Feb 2008, Anthony Liguori wrote:
I would really like to use OpenGL on non-Apple platforms. OpenGL gives
much better scaling than SDL. Typically, and OpenGL app has very little
platform specific code. It would be nice if we could use similar code
Hi,
On Tue, 5 Feb 2008, Anthony Liguori wrote:
> I would really like to use OpenGL on non-Apple platforms. OpenGL gives
> much better scaling than SDL. Typically, and OpenGL app has very little
> platform specific code. It would be nice if we could use similar code
> here.
But SDL runs on
Warner Losh wrote:
From: Andreas Färber <[EMAIL PROTECTED]>
Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Date: Tue, 5 Feb 2008 13:58:28 +0100
Am 05.02.2008 um 12:30 schrieb Ian Jackson:
I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be
better for qemu's
Alexander Graf wrote:
On Feb 1, 2008, at 5:45 PM, Mike Kronenberg wrote:
After a little discussion on the list, I made this patch for cocoa.m,
to replace CoreGraphic by OpenGL.
Great! Thank you.
It's way faster than CG, but it requires a Mac with OpenGL capable
Graphics Card and at least 8m
From: Andreas Färber <[EMAIL PROTECTED]>
Subject: Re: [Qemu-devel] Making qemu use 10.0.3.x not 10.0.2.x
Date: Tue, 5 Feb 2008 13:58:28 +0100
>
> Am 05.02.2008 um 12:30 schrieb Ian Jackson:
>
> > I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be
> > better for qemu's default
Am 05.02.2008 um 12:30 schrieb Ian Jackson:
I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be
better for qemu's default range to be a randomly chosen one.
Please don't randomly choose a default subnet; knowing that QEMU uses
10.0.2.x allows to adapt to this. If however
Fabrice Bellard writes ("[Qemu-devel] Re: [PATCH 1/6] Use correct types to
enable > 2G support"):
> Paul Brook wrote: If we ever implement >2G ram on a 32-bit host this
> > may need some rethinking. We can deal with that if/when it
> > happens though. Requiring a 64-bit host for large quantities
Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not
10.0.2.x"):
> Samuel Thibault <[EMAIL PROTECTED]> writes:
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
>
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8
Andreas Schwab, le Tue 05 Feb 2008 11:32:30 +0100, a écrit :
> Samuel Thibault <[EMAIL PROTECTED]> writes:
>
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
>
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?
Precisely thanks
Samuel Thibault <[EMAIL PROTECTED]> writes:
> Mmm, actually, shouldn't qemu use a more "private" network like a
> RFC1918 172.16.0.0/12 network?
In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxf
On Feb 1, 2008, at 5:45 PM, Mike Kronenberg wrote:
After a little discussion on the list, I made this patch for
cocoa.m, to replace CoreGraphic by OpenGL.
Great! Thank you.
It's way faster than CG, but it requires a Mac with OpenGL capable
Graphics Card and at least 8mb of VRAM.
I think s
This patch extends the existing support for the Mach-O binary format
in dyngen from PowerPC to PowerPC, i386 and x86_64.
v2 now includes support for TCG
qemu-macho.patch
Description: Binary data
This patch implements Mac OS X specific parts that are necessary to
get x86_64 versions of qemu working.
It does:
- add osx x86_64 detection to configure
- add -fomit-frame-pointer if available
- set the pagezero size to <4GB, so 32bit lea still works
- fix redeclarations of int64_t and uint64
No Mac OS X specific patches are required to get i386 host support
with gcc4 non-working ;-).
This patch implements Mac OS X specific parts that are necessary to
get i386 and x86_64 versions of qemu working. Since both hosts need
this patch, I seperated it from the architecture specific ones.
It does:
- not force always_inline
- only define [u]intXX types if they are not already defi
Hi,
supporting Mac OS X on Intel has been a long standing issue. The Q
project has done a fabulous job maintaining patches that make things
work for i386 Mac OS X, but do invasive changes to qemu internals.
This set of patches attempts to make Mac OS X host support as
compatible as possib
31 matches
Mail list logo
