[Qemu-devel] WE NEED GCC 4 please
could you please consider supporting gcc 4 ? SERVIZIO VOICE: TELEFONA e INVIA SMS dal tuo computer a tariffe vantaggiose! Scopri come telefonare e videochiamare gratis da pc a pc. http://voice.repubblica.it
Re: [Qemu-devel] [PATCH] Capture network traffic
Hi, On 18/12/2007, Balazs Attila-Mihaly (Cd-MaN) <[EMAIL PROTECTED]> wrote: > Here goes version 0.3 of my packet capture patch. I rewritten it to be a > custom VLANClient which implements the capturing part in its fd_read > proceudre, rather than adding additional properties to the VLAN structure. > Monitor support is also present. You can't cast the result of get_param_value() to char * because (as expected) you get this: [EMAIL PROTECTED] qemu-cvs]$ x86_64-softmmu/qemu-system-x86_64 -net capture,file=out a Segmentation fault Also I'm sure the use of asprintf() will upset the non-Linux-or-BSD users. I don't think you need to check for memory allocation failures (the message will not display anyway in such case, because monitor allocates memory for that). It will be nice if you can remove stray spaces on end of lines/empty lines. The PCAPHeader struct probably should have a __packed__ attribute. Thanks, Andrew
[Qemu-devel] Modding an Arch
I'm hoping to do some research on a slightly odd form of resource allocation in an arch. Not sure which yet, hoping for some advise. My only real world assembler practice has been 68K (a while ago), but I have coded in my own assembler before on another homebrew very limited odd VM. I'm going to be changing these things, whilst keeping the rest constant, - how IRQs are assigned to handlers - how memory is protected - boot sequence - security levels - what the bios does when it finds devices - possibly adding a few instructions to the arch to facillitate the above - Paging in some fashion (might be removed) These will be added - security in interactions with a special persistant memory (hard disk alike) which will be what is booted - a device handled by the arch (rather than software) My goal is to get a demo that works up quickly-ish (a year or two while learning the arch, doing research and writing a very minimal demo OS probably in asm), but can also be extended nicely into a proper working system sometime down the line. I don't care about backwards compatibility. But easy porting tools across would be nice. So my questions are, 1) Is qemu a sensible thing to do this in. 2) If so which arch should I mod 3) What should I look at apart from stuff referenced in this thread http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00157.html Feel free to message me off-list if you want details of the arch, they are a bit raw still though, as I'm still in the process of figuring them out. Will Pearson
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
In message: <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> writes: : > In the absence of a global configuration file, a reasonably sane way to : > support this configuration system wide is to use an environmental : > variable. QEMU already uses a number of global variables for : > configuring audio options. : : I'd really prefer we didn't do this, and preferably obsoleted/removed the : existing environment variables. IMHO using environment variables is a really : bad idea and should be avoided wherever possible. : : Environment variables are about the worst user interface I can think of. For a : start they're a global resource, which is limited on some systems. : It's also extremely hard to determine what environment a user is running. This : makes reproducing user bugs somewhere between hard and impossible. Other than quick, developer friendly hacks, the only time environment variables make sense is to select globally something. A hypothetical QEMU_ROOT might be useful for selecting which tree of files qemu reads from. If you had multiple shells and wanted to run different installations of qmeu in each, this would be useful. But to have them control more fine grain options is something to be avoided. At least that's how I've selected them in my programs in the past Please note: I'm not saying this is the right way to select between multiple installed versions of qemu, just an example of when it makes sense. Warner
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
Paul Brook wrote: In the absence of a global configuration file, a reasonably sane way to support this configuration system wide is to use an environmental variable. QEMU already uses a number of global variables for configuring audio options. I'd really prefer we didn't do this, and preferably obsoleted/removed the existing environment variables. IMHO using environment variables is a really bad idea and should be avoided wherever possible. Any suggestion on an alternative mechanism then? Can we introduce a config file and slowly introduce options into it? Regards, Anthony Liguori Environment variables are about the worst user interface I can think of. For a start they're a global resource, which is limited on some systems. It's also extremely hard to determine what environment a user is running. This makes reproducing user bugs somewhere between hard and impossible. Paul
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Hi, On Sat, 19 Jan 2008, Markus Hitter wrote: > Am 19.01.2008 um 12:16 schrieb Johannes Schindelin: > > > On Sat, 19 Jan 2008, Markus Hitter wrote: > > > > > Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: > > > > > > > Even if another system starts working, if you break existing > > > > users, you did something wrong. And if you don't care, and don't > > > > mind giving existing users a hard time, you cannot be helped and > > > > should go somewhere else. > > > > > > So you have to be backwards oriented and willing to live with bugs > > > to join your world. Good to know. > > > > How dare you misrepresenting my words like that? > > Because for me it's what you essentially said. > > In search of a friendly agreement I'll continue off list. I think the open assumption that I am "backwards oriented" just for claiming that breaking existing setups made a friendly agreement rather hard to reach. So this discussion is no longer wasting my time from... right now
Re: [Qemu-devel] Re: [PATCH] USB serial device
andrzej zaborowski, le Sat 19 Jan 2008 14:05:20 +0100, a écrit : > I applied the patch even though the old values worked ok too. The old values weren't in linux 2.6.12 for instance, and it looks like the new ones are the default ones for the FTDI builderr, so it should be fine now. > I also added a chr_close callback for -serial stdio so that I can do > usb_add serial::stdio, then usb_del and usb_add serial::stdio again > without getting an error on opening "stdio". Good, thanks! Samuel
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
> In the absence of a global configuration file, a reasonably sane way to > support this configuration system wide is to use an environmental > variable. QEMU already uses a number of global variables for > configuring audio options. I'd really prefer we didn't do this, and preferably obsoleted/removed the existing environment variables. IMHO using environment variables is a really bad idea and should be avoided wherever possible. Environment variables are about the worst user interface I can think of. For a start they're a global resource, which is limited on some systems. It's also extremely hard to determine what environment a user is running. This makes reproducing user bugs somewhere between hard and impossible. Paul
[Qemu-devel] kqemu working with qemu cvs?
Is there a version of kqemu that works with the cvs version of qemu? When I tried to run qemu with kqemu, it hung while booting SuSE Linux. And I'm sorry if this is the second one with this question; MDaemon seems to like to block me when I use Outlook Express. _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
Re:Re: [Qemu-devel] How to run gpe on qemu
On 19/01/2008, 赵经纬 <[EMAIL PROTECTED]> wrote: > I want run gpe-image on qemuarm. and I have got a gpe-image through > openembedded,like this: > > [EMAIL PROTECTED]:~/stuff$ bitbake gpe-image > NOTE: Handling BitBake files: - (5018/5018) [100 %] > NOTE: Parsing finished. 4783 cached, 0 parsed, 235 skipped, 0 masked. > NOTE: build 200801181833: started > OE Build Configuration: > BB_VERSION = "1.89" > OE_REVISION= "6c8738ab25503f1d21271ec5f6abc1950ace" > TARGET_ARCH= "arm" > TARGET_OS = "linux-gnueabi" > MACHINE= "qemuarm" > DISTRO = "angstrom" AFAIK the "qemuarm" machine is an alias for verstilepb in OE. So just use the versatilepb and pass the rootfs image as -hda (if I remember ok). You might want to have a look at the poky-linux scripts to run qemu with OE-built images (see pokylinux.org). Poky uses a modified OE with facilities to run it in qemu. Beside "verstilepb", you can also run GPE under the "cheetah" machine and "spitz" and "akita". (this is GPE on cheetah: http://www.numenor.art.pl/balrog/palmte/gpe-system-emulator.jpeg) pass the rootfs image as -hda will cause "booting from hardisk",and for a long time it doesn't work. The website give me a hit:qemu gpe-image-qemuarm.jffs2 -m 128 -mtdblock -kernel zImage-qemuarm.bin -no-kqemu -usb and the systerm says:invalid option -- '-mtdblock' thanks for your replay! Zhao Jjingwei
Re: [Qemu-devel] How to run gpe on qemu
Hi, On 19/01/2008, 赵经纬 <[EMAIL PROTECTED]> wrote: > I want run gpe-image on qemuarm. and I have got a gpe-image through > openembedded,like this: > > [EMAIL PROTECTED]:~/stuff$ bitbake gpe-image > NOTE: Handling BitBake files: - (5018/5018) [100 %] > NOTE: Parsing finished. 4783 cached, 0 parsed, 235 skipped, 0 masked. > NOTE: build 200801181833: started > OE Build Configuration: > BB_VERSION = "1.89" > OE_REVISION= "6c8738ab25503f1d21271ec5f6abc1950ace" > TARGET_ARCH= "arm" > TARGET_OS = "linux-gnueabi" > MACHINE= "qemuarm" > DISTRO = "angstrom" AFAIK the "qemuarm" machine is an alias for verstilepb in OE. So just use the versatilepb and pass the rootfs image as -hda (if I remember ok). You might want to have a look at the poky-linux scripts to run qemu with OE-built images (see pokylinux.org). Poky uses a modified OE with facilities to run it in qemu. Beside "verstilepb", you can also run GPE under the "cheetah" machine and "spitz" and "akita". (this is GPE on cheetah: http://www.numenor.art.pl/balrog/palmte/gpe-system-emulator.jpeg) Cheers
Re: [Qemu-devel] Re: [PATCH] USB serial device
Hi, On 17/01/2008, Samuel Thibault <[EMAIL PROTECTED]> wrote: > andrzej zaborowski, le Thu 17 Jan 2008 23:25:04 +0100, a écrit : > > Thanks, committed although I hoped for something that lets easily test > > that the adapter works, e.g. so that after a usb_add serial:...:stdio > > you can do cat /dev/ttyXXXN in the guest and see what's being typed on > > qemu's stdin. I got the device detected without problems but Linux > > didn't create any new serial ports. Sorry, that was a user error (mine), I had been using the generic usb-serial.ko driver instead of the FTDI specific one. Now it indeed works like a charm. > > Oh? That's odd, I've no problem here, /dev/ttyUSB0 appears like a charm > and cat & echo work fine. We should probably use another product ID by > default, which would be more widely automatically recognized. Here is a > patch. Thanks, I applied the patch even though the old values worked ok too. If they were better for some reason please tell. I also added a chr_close callback for -serial stdio so that I can do usb_add serial::stdio, then usb_del and usb_add serial::stdio again without getting an error on opening "stdio". Cheers
[Qemu-devel] qemu qemu-doc.texi vl.c hw/usb-serial.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski 08/01/19 13:00:43 Modified files: . : qemu-doc.texi vl.c hw : usb-serial.c Log message: Change the usb-serial product ID to a more widely recognised value (Samuel Thibault). Implement chr_close callback for "stdio" so that it can be closed and reopened. Free chr devices after they're closed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.181&r2=1.182 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.399&r2=1.400 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-serial.c?cvsroot=qemu&r1=1.1&r2=1.2
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Am 19.01.2008 um 12:16 schrieb Johannes Schindelin: Hi, On Sat, 19 Jan 2008, Markus Hitter wrote: Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: Even if another system starts working, if you break existing users, you did something wrong. And if you don't care, and don't mind giving existing users a hard time, you cannot be helped and should go somewhere else. So you have to be backwards oriented and willing to live with bugs to join your world. Good to know. How dare you misrepresenting my words like that? Because for me it's what you essentially said. In search of a friendly agreement I'll continue off list. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Hi, On Sat, 19 Jan 2008, Markus Hitter wrote: > Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: > > > Even if another system starts working, if you break existing users, > > you did something wrong. And if you don't care, and don't mind giving > > existing users a hard time, you cannot be helped and should go > > somewhere else. > > So you have to be backwards oriented and willing to live with bugs to > join your world. Good to know. How dare you misrepresenting my words like that? Cutting out the first sentence which read something like "supporting new systems is good"? Pissed, Dscho
Re: [Qemu-devel] [kqemu] BR and presentation
> > I've got some other problems, maybe this is linked : > > 1/ I installed slackware-12.0 on a vm (the same OS as hosted, may > > I consult a psychanalist ?), on qcow2 virtual disk. The > > installation and use works fine, full virtualisation enabled, and > > today, without doing nothing particular, the vm won't boot : no > > hard disk bootable. I boot on my cd, I fdisk, and I just cry and > > constast my disk was just empty : no partition, no swap, nothing, > > just a virgin hard drive, even though I used this virtual machine > > many time before ! And the matter is similar in 2/ > > 2/ When I tried to snapshot my virtual Slackware-12.0 (this > > Slackware is for make perfect package/SlackBuild on a full > > installed and vanilla slackware), my hard disk worked, and few > > seconds later, the vm just stop. When I try to boot, same error as > > in 1/. And when I boot my rescue CD on it, same thing. This last > > point (trying to make a snapshot) has been made 3 times ! And 3 > > times the same errors. Now I'm going to use qcow instead of qcow2 > > and just cp/dd my virtual disk instead of using snapshot. > > > > I hope I help you a little, see you and thx > > If I'm not mistaken, the 0.9.0 release had an issue with corrupting > the qcow2 image when it was around 2GB. > thx for info. My virtual disk in around 5 Gb. I'm going to try with another format.
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Am 18.01.2008 um 20:28 schrieb Johannes Schindelin: Even if another system starts working, if you break existing users, you did something wrong. And if you don't care, and don't mind giving existing users a hard time, you cannot be helped and should go somewhere else. So you have to be backwards oriented and willing to live with bugs to join your world. Good to know. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Qemu-devel] How to run gpe on qemu
Hi all: I want run gpe-image on qemuarm. and I have got a gpe-image through openembedded,like this: [EMAIL PROTECTED]:~/stuff$ bitbake gpe-image NOTE: Handling BitBake files: - (5018/5018) [100 %] NOTE: Parsing finished. 4783 cached, 0 parsed, 235 skipped, 0 masked. NOTE: build 200801181833: started OE Build Configuration: BB_VERSION = "1.8.9" OE_REVISION= "6c8738ab25503f1d21271ec5f6abc1950ace" TARGET_ARCH= "arm" TARGET_OS = "linux-gnueabi" MACHINE= "qemuarm" DISTRO = "angstrom" DISTRO_VERSION = "2008.1-test-20080118" TARGET_FPU = "soft" now,I don't know how I can run gpe on qemu,please give me some help. it would be best that you can give me some detailed way. looking forward for your replay! Zhao Jingwei
