e
+env->thread_id = getpid();
+#endif
*penv = env;
hmm... maybe I'm missing something, but in Linux at least I think you
would prefer this to be gettid() rather then getpid as each CPU has it's
own thread, not a different process.
No?
Gilad
--
Gilad Ben-Yossef <[E
Jamie Lokier wrote:
Gilad Ben-Yossef wrote:
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+
bunch of geeks here that would really like to best test this... :-)
Thanks!
Gilad
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Codefidence. A name you can trust(tm)
http://www.codefidence.com
Phone: +972.3.7515563 ext. 201 | Cellular: +972.52.8260388
SIP: [EMAIL PROTECTED] | Fax: +972.3.7515503
uprises mid run) and is maintained as part of
qemu
with exact same functionality.
If you think users other then us will use the patch (and we believe they will),
we think it'll be useful for this to be included in qemu mainline.
Anyway, thanks for reading this long email and for qemu VNC su
command line as they're meaningless once you've
migrated.
That, I have no answer for. What do you do with the Unix domain socket?
open it by path/filename on the new machines?
Gilad
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Codefidence. A name you can trust(tm)
http://www.codefidenc
Anthony Liguori wrote:
The machine running qemu has a web based interface to start VMs.
A user asks for a new VM to start by browsing to a URL. The CGI
implmenting that URL will start a new qemu instance, send to the user
web browser an HTML page with a JAVA VNC viewer embedded and terminate.
h besides increasing the coolness factor, though ;-)
Actually, I can think of some very useful things to do with a virtual
wireless car din qemu, so as wireless related application testing,
wireless mesh network simulations etc etc...
This is beyond cool factor. It's useful.
Just my
