In message: <[EMAIL PROTECTED]>
Ben Taylor <[EMAIL PROTECTED]> writes:
: Start with the configure script and Makefiles, and any very specfic, targeted
: and small patches and let those changes slowly propogate out.
Most of the FreeBSD ports patches are relatively easy to justify and
e
Hi,
After I used TAP device by -net nic -net tap,ifname=mytap and I tried to use
user mode network by -net nic -net user, a Windows XP guest doesn't get
IP address from a built-in DHCP server.
It is fixed by an attached patch.
DHCPRELEASE and DHCPNACK are introduced.
DHCPRELEASE code is borrowe
Hi,
I made a Kqemu-1.3.0pre11 installer.
http://www.h6.dion.ne.jp/~kazuw/qemu-win/Kqemu-1.3.0pre11-install.exe
Please uninstall your old version before installing it. It is "KQEMU
virtualization module for QEMU" in the control panel->add/remove software.
The new Kqemu is installed as "QEMU Accere
Ok FreeBSD Support round one..
Be gentle this is my first attempt at working with the rest of this
community..
Files it modifies and the reasons are as follows
configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
not need -ltr
Makefile.target - Once again uses HOST_FREE
> So should I make a separate patch for each modified file?
No. You should break changes into logically independent patches.
It is ok for a single patch to touch multiple files, but it should only fix
one thing.
Paul
___
Qemu-devel mailing list
Qemu-
On Monday 19 February 2007 21:08, Ben Taylor wrote:
> Having been in your shoes, the only thing I can tell you is start
> small. Be able to justify your patches and change as little as
> possible. Be smart about how you code things if there are
> specific reasons. And get ready for a long haul.
On Monday 19 February 2007 20:46, Paul Brook wrote:
> > This is a sidetrack here... But is it at all possible to make future
> > releases of the source more FreeBSD friendly?
>
> If someone puts in the effort to make it so, yes.
>
> Note that dumping the current patches from FreeBSD ports on the li
Christopher Olsen <[EMAIL PROTECTED]> wrote:
> This is a sidetrack here... But is it at all possible to make future releases
> of the source more FreeBSD friendly?
>
> I am willing to work off a specified codebase to bring it up to FreeBSD speed
> so it can be easily maintained from there
> This is a sidetrack here... But is it at all possible to make future
> releases of the source more FreeBSD friendly?
If someone puts in the effort to make it so, yes.
Note that dumping the current patches from FreeBSD ports on the list is
generally not sufficient. Blindly posting patches witho
On Monday 19 February 2007 20:11, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 20 Feb 2007, Daniel P. Berrange wrote:
> > Well there's a number of plausible options
> >
> > - Password, but using challenge/resonse (either plain or TLS channel)
> > - Simple password (assuming a TLS encypted channe
This is a sidetrack here... But is it at all possible to make future releases
of the source more FreeBSD friendly?
I am willing to work off a specified codebase to bring it up to FreeBSD speed
so it can be easily maintained from there...
Because unfortunately out of the box it doesn't build.
Hi,
On Tue, 20 Feb 2007, Daniel P. Berrange wrote:
> Well there's a number of plausible options
>
> - Password, but using challenge/resonse (either plain or TLS channel)
> - Simple password (assuming a TLS encypted channel)
> - Whitelist based on client TLS certificate (common name/fingerpr
On Mon, Feb 19, 2007 at 06:45:54PM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
> >
> >>On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
> >>
> >>>On the technical side, adding OpenSSL support in the cu
On Monday 19 February 2007 19:45, Anthony Liguori wrote:
> While this is all well and good, there is still the fundamental problem
> of how does one associate credentials with a VM. The actual security
> mechanism is, IMHO, just an implementation detail.
>
> Regards,
>
> Anthony Liguori
>
Very tr
Daniel P. Berrange wrote:
On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
On the technical side, adding OpenSSL support in the current VNC
implementation is QEMU seems easy (OpenSSL has a non blocking API which
Hi,
This patch fixes chaining of CPU instances. It was simply trashed with the
memcpy() thus causing problems in threaded programs (N > 2): an infinite
loop in next cpu_init().
--- qemu-0.9.0/linux-user/syscall.c.cpuchain2007-02-13 14:41:12.0
+0100
+++ qemu-0.9.0/linux-user/syscall.c
On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
> On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
> >
> > On the technical side, adding OpenSSL support in the current VNC
> > implementation is QEMU seems easy (OpenSSL has a non blocking API which
> > can be used with the
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/02/20 00:18:37
Modified files:
. : Changelog
Log message:
Record important changes.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.129&r2=1.13
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/02/20 00:12:07
Modified files:
. : qemu-doc.texi vl.c
slirp : tftp.c
Log message:
Change -tftp option to take a root directory, by Anthony Liguori.
CVSWeb URLs
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/02/20 00:07:50
Modified files:
slirp : tftp.c tftp.h
Log message:
Add OACK support to slirp TFTP server, by Anthony Liguori.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/sl
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 07/02/20 00:05:08
Modified files:
. : qemu-doc.texi vl.c vl.h
slirp : bootp.c
Log message:
Add -bootp option for slirp, by Anthony Liguori.
CVSWeb URLs:
http://cv
Hi,
On Mon, 19 Feb 2007, Fabrice Bellard wrote:
> On the technical side, adding OpenSSL support in the current VNC
> implementation is QEMU seems easy (OpenSSL has a non blocking API which
> can be used with the current callback API).
Goodbye compatibility.
I mean, you _can_ just ask for brea
On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
>
> On the technical side, adding OpenSSL support in the current VNC
> implementation is QEMU seems easy (OpenSSL has a non blocking API which
> can be used with the current callback API).
>
> Fabrice.
>
Good call... Let me look into that.
Daniel P. Berrange wrote:
On Mon, Feb 19, 2007 at 12:41:53PM -0500, Christopher Olsen wrote:
On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
Hi,
On Sun, 18 Feb 2007, Anthony Liguori wrote:
Christopher Olsen wrot
On Monday 19 February 2007 14:09, Daniel P. Berrange wrote:
> Guess you missed the 'unix' directory - I have compiled both server &
> client of VeNCrypt on Linux no trouble.
>
> > I'm gathering the problem here is that VNC is spinning off in many
> > directions... So any implementation on the QEMU
On Mon, Feb 19, 2007 at 12:41:53PM -0500, Christopher Olsen wrote:
>
> On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
> > On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > On Sun, 18 Feb 2007, Anthony Liguori wrote:
> > > > Christopher Olsen wr
I would like to be able to restore a snapshot from a disk image file
with read only permissions, for example stored on a cdrom.
QEMU checks if an image supports snapshots (bdrv_can_snapshot, etc)
and will fail if the disk is read only. As a quick test, I patched
out these checks and QEMU will bo
On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
> On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Sun, 18 Feb 2007, Anthony Liguori wrote:
> > > Christopher Olsen wrote:
> > > > Sorry I'll attempt to use the preferred patching method in the
> > >
On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 18 Feb 2007, Anthony Liguori wrote:
>
> > Christopher Olsen wrote:
> > > Sorry I'll attempt to use the preferred patching method in the future..
> > >
> > > Secure vnc auth method the default built in method f
Hi
I'm doing use qemu 0.8.2. I have just create my instance and all run
perfectly.
But, it's possible to assign a CPU(x) each individual instance? I have a
multicore platform.
IMHO yes, google for Linux CPU affinity
regards,
Mulyadi
___
Qe
Hi
Hi all,
I'm doing use qemu 0.8.2. I have just create my instance and all run
perfectly.
But, it's possible to assign a CPU(x) each individual instance? I have a
multicore platform.
IMHO yes, google for Linux CPU affinity.
regards,
Mulyadi
Understandable...
However I'm not sure about others and how they intend to use QEMU.. But I for
one know that I do have a use for authentication within the VNC session..
You're right that it's supposed to be a standard protocol but it doesn't
appread to be from the many different flavors of VN
Hi all,
I'm doing use qemu 0.8.2. I have just create my instance and all run
perfectly.
But, it's possible to assign a CPU(x) each individual instance? I have a
multicore platform.
Thank you in advance
Antonio
___
Qemu-devel mailing list
Qemu-dev
Patch from Debian patchset in the attachment.
--- linux-user/syscall.c.orig 2006-11-05 07:07:19.0 +0200
+++ linux-user/syscall.c2006-11-05 07:07:25.0 +0200
@@ -3972,6 +3982,22 @@ long do_syscall(void *cpu_env, int num,
case TARGET_NR_getdomainname:
goto unim
On [Mon, 19.02.2007 16:44], Kirill A. Shutemov wrote:
> Fixed Debian patch in the attachment. uselib is deprecated, but I think it
> should be implemented by qemu, because it's in the kernel yet.
Sorry, attached.
--- linux-user/syscall.c.orig 2006-11-05 07:07:19.0 +0200
+++ linux-user/sy
Fixed Debian patch in the attachment. uselib is deprecated, but I think it
should be implemented by qemu, because it's in the kernel yet.
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.
Hi,
On Mon, 19 Feb 2007, Christopher Olsen wrote:
> I've done some further thought and investigation and as far as using
> QEMU inside a Unix environment, I see no reason as to why the
> authentication couldn't be tied into PAM...
Because this is supposed to be a standard protocol, meant for w
Patch from Debian patchset in the attachment.
--- linux-user/syscall.c.orig 2006-11-05 07:07:19.0 +0200
+++ linux-user/syscall.c2006-11-05 07:07:25.0 +0200
@@ -3856,7 +3863,9 @@ long do_syscall(void *cpu_env, int num,
goto unimplemented;
#ifdef TARGET_NR_mincore
Patch from Debian patchset in the attachment
--- linux-user/syscall.c.orig 2006-11-05 07:07:19.0 +0200
+++ linux-user/syscall.c2006-11-05 07:07:25.0 +0200
@@ -3947,7 +3956,8 @@ long do_syscall(void *cpu_env, int num,
ret = get_errno(gettid());
break;
Fixed version of the patch in the attacment. Please, comment.
--- qemu-0.8.2/linux-user/path.c.orig 2006-12-21 17:16:03 +0200
+++ qemu-0.8.2/linux-user/path.c2006-12-21 17:14:08 +0200
@@ -1,147 +1,37 @@
/* Code to mangle pathnames into those matching a given prefix.
eg. open("/lib/fo
On Mon, Feb 19 2007, Thiemo Seufer wrote:
> Thiemo Seufer wrote:
> [snip]
> > > > > Why is nsector uint32_t to begin with?
> > > >
> > > > Because nobody sent a patch to fix it, I figure.
> > >
> > > Actually I seem to recall it's because it's being overloaded for
> > > requests that are > 256 se
Thiemo Seufer wrote:
[snip]
> > > > Why is nsector uint32_t to begin with?
> > >
> > > Because nobody sent a patch to fix it, I figure.
> >
> > Actually I seem to recall it's because it's being overloaded for
> > requests that are > 256 sectors. It would be a good cleanup to get rid
> > of that a
Jens Axboe wrote:
> On Mon, Feb 19 2007, Thiemo Seufer wrote:
> > Jens Axboe wrote:
> > > On Mon, Feb 19 2007, Thiemo Seufer wrote:
> > > > CVSROOT:/sources/qemu
> > > > Module name:qemu
> > > > Changes by: Thiemo Seufer 07/02/19 00:59:34
> > > >
> > > > Modified files:
> > >
In regards to all this
Johannes... You're correct the challenge response method for authentication
inside of VNC isn't secure at all it's like locking your screen door at home
will keep most people out just not the ones who really want to get in...
I've done some further thought and investigati
On Mon, Feb 19 2007, Thiemo Seufer wrote:
> Jens Axboe wrote:
> > On Mon, Feb 19 2007, Thiemo Seufer wrote:
> > > CVSROOT: /sources/qemu
> > > Module name: qemu
> > > Changes by: Thiemo Seufer 07/02/19 00:59:34
> > >
> > > Modified files:
> > > hw : ide.c
> > >
> >
Jens Axboe wrote:
> On Mon, Feb 19 2007, Thiemo Seufer wrote:
> > CVSROOT:/sources/qemu
> > Module name:qemu
> > Changes by: Thiemo Seufer 07/02/19 00:59:34
> >
> > Modified files:
> > hw : ide.c
> >
> > Log message:
> > Ignore special flags in nsector variab
Hello Shane.
I have successfully added instruction counters to QEMU with a low run-time
overhead. I cannot give you the code but I can tell you how I did it.
1: Make sure that QEMU knows which block is the current_tb. What I did was to
update the goto_tb block to update the current_tb pointer
On Mon, Feb 19 2007, Thiemo Seufer wrote:
> CVSROOT: /sources/qemu
> Module name: qemu
> Changes by: Thiemo Seufer 07/02/19 00:59:34
>
> Modified files:
> hw : ide.c
>
> Log message:
> Ignore special flags in nsector variable.
>
> CVSWeb URLs:
> http://cvs.s
48 matches
Mail list logo
