Please don't feed the trolls :-) Best thing to do is just ignore messages
like this.
Regards,
Anthony Liguori
On Sat, 29 Jul 2006 14:13:44 -0400, Leonardo E. Reiter wrote:
> Don't use it if you don't like the license... the author has the right to
> license it how he wants. Or... you can deve
On Sat, 2006-07-29 at 14:56 -0700, Jonathan Kalbfeld wrote:
> To be honest, I'd be willing to PAY Fabrice for QEMU.
>
> What else can I use to boot windows 2k on my sun blade 2000 at work?
>
> jonathan
I have never seen anyone say why KQEMU is closed, though, at least
beyond any speculation. And
To be honest, I'd be willing to PAY Fabrice for QEMU.
What else can I use to boot windows 2k on my sun blade 2000 at work?
jonathan
On 7/29/06, Karel Gardas <[EMAIL PROTECTED]> wrote:
On Sat, 29 Jul 2006, Karlos . wrote:
>
> QEMU Accelerator license is not ethical.
>
> Open the code unless y
On Sat, 29 Jul 2006, Leonardo E. Reiter wrote:
Brad,
I think the 0x20 (32ms) value might be fine for something like VNC
display, but on a local display the mouse response is noticeably slow
(for me at least.) I tried using 0x0a (10), same as the plain USB
mouse, but the idle CPU utilization wa
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 06/07/29 19:09:31
Modified files:
. : cpu-exec.c
Log message:
Arm host build fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.83&r2=1.84
_
Brad,
I think the 0x20 (32ms) value might be fine for something like VNC
display, but on a local display the mouse response is noticeably slow
(for me at least.) I tried using 0x0a (10), same as the plain USB
mouse, but the idle CPU utilization was still around 10%. What is
really odd is that th
Don't use it if you don't like the license... the author has the right
to license it how he wants. Or... you can develop your own version, or
use/contribute to the open source alternative, qvm86.
- Leo Reiter
Karlos . wrote:
>
> QEMU Accelerator license is not ethical.
>
> Open the code unless
On Sat, 29 Jul 2006, Karlos . wrote:
QEMU Accelerator license is not ethical.
Open the code unless you have something to hide.
Karlos,
do you think it's ethical to attack Fabrice for his kernel module license
choice? Please consider what you've done for Qemu yourself, what Qemu
user/deve
QEMU Accelerator license is not ethical. Open the code unless you have something to hide.
LLama Gratis a cualquier PC del Mundo.Llamadas a fijos y móviles desde 1 céntimo por minuto.http://es.voice.yahoo.com___
Qemu-devel mailing list
Qemu-devel@nongnu
How about compromising, and making the patch a run time option. Presumably this is only a problem when the virtual machine is not properly shutdown. For those ho want the extra security of knowing the data will be written regardless of the shutdown status they can enable the flag. By default it
> Easy to do with the fsync infrastructure, but probably not worth
> doing since people are working on the AIO I/O backend, which would
> allow multiple outstanding writes from a guest. That, in turn,
> means I/O completion in the guest can be done when the data really
> hits disk, but without a p
Paul Brook wrote:
On Saturday 29 July 2006 15:59, Rik van Riel wrote:
Fabrice Bellard wrote:
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly.
This means that write ordering is not preserved, and on a power
failu
On Saturday 29 July 2006 15:59, Rik van Riel wrote:
> Fabrice Bellard wrote:
> > Hi,
> >
> > Using O_SYNC for disk image access is not acceptable: QEMU relies on the
> > host OS to ensure that the data is written correctly.
>
> This means that write ordering is not preserved, and on a power
> failu
Fabrice Bellard wrote:
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly.
This means that write ordering is not preserved, and on a power
failure any data written by qemu (or Xen fully virt) guests may
not be pres
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly. Even the current
'fsync' support is questionnable to say the least !
Please don't mix issues regarding QEMU disk handling and the underlying
hypervisor/host OS b
15 matches
Mail list logo
