Thanks Stuart.
--
best regards
q#
Hi!
On Sun, Jan 20, 2008 at 02:43:59PM +0100, Tobias Ulmer wrote:
(i havn't really tested this, but can't we drop the standard qemu and
make qemu-kqemu the default? In my [admitedly short] testing, this works
fine and just prints a message that it can't load kqemu)
Seems people reported problems
On Mon, 21 Jan 2008, Hannah Schroeter wrote:
Seems people reported problems with kqemu, so I'm not in favor of
dropping the non-kqemu variant.
The point is that qemu should work fine with or without kqemu with no
need of a FLAVOR.
Even if compiled with support for kqemu, qemu will proceed in
On Mon, Jan 21, 2008 at 12:31:10PM +0100, Hannah Schroeter wrote:
Hi!
On Sun, Jan 20, 2008 at 02:43:59PM +0100, Tobias Ulmer wrote:
(i havn't really tested this, but can't we drop the standard qemu and
make qemu-kqemu the default? In my [admitedly short] testing, this works
fine and just
Hi!
On Mon, Jan 21, 2008 at 12:41:29PM +0100, Antoine Jacoutot wrote:
On Mon, 21 Jan 2008, Hannah Schroeter wrote:
Seems people reported problems with kqemu, so I'm not in favor of
dropping the non-kqemu variant.
The point is that qemu should work fine with or without kqemu with no
need of a
Hi!
On Mon, Jan 21, 2008 at 02:40:20PM +0100, Stefan Sperling wrote:
[...]
Can one, then, also disable kqemu in the kqemu variant of qemu even when
the kqemu kernel module is loaded, e.g. with a command line option?
Yes.
Quoting http://fabrice.bellard.free.fr/qemu/kqemu-doc.html :
[...]
On Mon, Jan 21, 2008 at 02:22:47PM +0100, Hannah Schroeter wrote:
Hi!
On Mon, Jan 21, 2008 at 12:41:29PM +0100, Antoine Jacoutot wrote:
On Mon, 21 Jan 2008, Hannah Schroeter wrote:
Seems people reported problems with kqemu, so I'm not in favor of
dropping the non-kqemu variant.
The point
Tobias Ulmer a écrit :
On Mon, Jan 21, 2008 at 12:31:10PM +0100, Hannah Schroeter wrote:
Hi!
On Sun, Jan 20, 2008 at 02:43:59PM +0100, Tobias Ulmer wrote:
(i havn't really tested this, but can't we drop the standard qemu and
make qemu-kqemu the default? In my [admitedly short]
On Mon, Jan 21, 2008 at 10:32:55PM +0100, DbD wrote:
I can confirm, there are no problem if kernel-kqemu is not enable.
My conclusions about qemu-kqemu, the are 3 options :
- Default, no option : User acceleration (qemu compile with kqemu)
- no-kqemu : Disable all acceleration
-
On 2008/01/22 00:50, Mikolaj Kucharski wrote:
On Mon, Jan 21, 2008 at 10:32:55PM +0100, DbD wrote:
I can confirm, there are no problem if kernel-kqemu is not enable.
My conclusions about qemu-kqemu, the are 3 options :
- Default, no option : User acceleration (qemu compile with
Suppose you compiled qemu with kqemu flavor
if kqemu is loaded :
1) no kqemu at all :
$ qemu -no-kqemu
2) qemu with kqemu in user mode : (in this mode OpenBSD and NetBSD guests will
work, thanks to Adrian's patch to kqemu : patches/patch-common_monitor_c)
$ qemu
3) qemu with kqemu in kernel
Hi.
This diff does some cleaning and add missing stuffs to the newly
imported kqemu port.
- add missing RCS tags
- respect $CC
- add NO_REGRESS
- s/$LOCALBASE/$PREFIX
- lowercase email
- hook to the build
- add _kqemu user to infrastructure/db/user.list
Comments/OK?
--
AntoineIndex:
On Sun, Jan 20, 2008 at 11:42:13AM +0100, Antoine Jacoutot wrote:
Hi.
This diff does some cleaning and add missing stuffs to the newly imported
kqemu port.
- add missing RCS tags
- respect $CC
- add NO_REGRESS
- s/$LOCALBASE/$PREFIX
- lowercase email
- hook to the build
- add _kqemu
Yes minus the hooking to the build yet.
We need more test results for amd64.
On Sun, Jan 20, 2008 at 11:42:13AM +0100, Antoine Jacoutot wrote:
Hi.
This diff does some cleaning and add missing stuffs to the newly imported
kqemu port.
- add missing RCS tags
- respect $CC
- add NO_REGRESS
On Sun, Jan 20, 2008 at 11:42:13AM +0100, Antoine Jacoutot wrote:
Hi.
This diff does some cleaning and add missing stuffs to the newly imported
kqemu port.
- add missing RCS tags
- respect $CC
- add NO_REGRESS
- s/$LOCALBASE/$PREFIX
- lowercase email
- hook to the build
- add _kqemu
On Sun, 20 Jan 2008, Tobias Ulmer wrote:
(i havn't really tested this, but can't we drop the standard qemu and
make qemu-kqemu the default? In my [admitedly short] testing, this works
fine and just prints a message that it can't load kqemu)
If that doesn't introduce any bad side effects, I'm
I was cautious in how I enabled this for now. It does change
the codepath. I'd like to give the wider audience of ports testers
the benefit of giving feedback on this. In the absence of any issues
running qemu w/out kqemu, I'll consider it in a few weeks.
Thanks,
On Sunday 20 January 2008
Ok.
On Sunday 20 January 2008 04:42:13 Antoine Jacoutot wrote:
Hi.
This diff does some cleaning and add missing stuffs to the newly
imported kqemu port.
- add missing RCS tags
- respect $CC
- add NO_REGRESS
- s/$LOCALBASE/$PREFIX
- lowercase email
- hook to the build
- add _kqemu user
18 matches
Mail list logo
