[Qemu-devel] Release: VMKnoppix_x86x86_64(with httpfs, ftpfs, http-fuse) ISO file for HttpDisk
Dear, We released new VMKnoppix(with httpfs,ftpfs, http-fuse) for x86 and x86_64. http://unit.aist.go.jp/itri/knoppix/vmknoppix/index-en.html We also released ISO file for HttpDisk with Win-QEMU and VMKnoppix. http://openlab.jp/oscircular/httpdisk/index.html They boot Guest-OS with a ISO file on a HTTP/FTP server! = VMKnoppix(with httpfs,ftpfs, http-fuse) for x86 andx86_64 = *** Features * Guest OS boots form an ISO file on a HTTP/FTP server using httpfsftpfs. It doesn't need to download the whole ISO file. GuestOS boots on Xen-HVM, KQEMU, QEMU and KVM. httpfs: http://httpfs.sourceforge.net/ ftpfs: http://ftpfs.sourceforge.net/ * VM change log. - Xen 3.1.0 (Both x86 and x86_64 are upgraded) knoppixHVM, knoppixU commands are prepared for easy run. - KVM16(x86), KVM 18(x86_64) - KQEMU (x86) - QMEU (x86 and x86_64) knoppix-qemu.sh command detects suitalbe one among KVM/KQEMU/QEMU. - User Mode Linux (x86 and x86_64) - VirtualBox (x86) * OS Circular - Xen-HVM and KVM/KQEMU/QEMU on x86 httpfuse-qemu.sh and httpfuse-hvm.sh commands are prepared for easy run. *** Usage * httpfs/ftpfs for virtual machine For KVM/KQEMU/QEMU # qemu-knoppix.sh http://***/Live-CD.iso # qemu-knoppix.sh ftp://***/Live-CD.iso # qemu-knoppix.sh file://tmp/Live-CD.iso qemu-knoppix.sh checks the machine and selects KVM/KQEMU/QEMU automatically. For Xen-HVM # knoppixHVM http://***/Live-CD.iso # knoppixHVM ftp://***/Live-CD.iso # knoppixHVM file://***/Live-CD.iso CAUTION: Xen-HVM is available on IntelVT or ADMV CPU only. CAUTION: Some ftp servers don't allow httpfs. Other than ISO file, qemu-knoppix.sh and knoppixHVM.sh accepts bootable disk format. For example, OS Zoo project offers many QEMU Disk Images. http://www.oszoo.org/wiki/index.php/Category:OS_images * HTTP-FUSE:OS Circular (for x86 only) For KVM/KQEMU/QEMU # httpfuse-qemu.sh For Xen-HVM # httpfuse-hvm.sh Current bootable OS is Debian GNU/Linux. *** Download * x86 version File name: knoppix_v5.1.1CD_20070104_xen3.1.0_vbox-20070620+IPAFont.iso MD5: f828056d465ff0fb7b5da183aac1b530 FTP: ftp://unit.aist.go.jp/itri/knoppix/iso/knoppix_v5.1.1CD_20070104_xen3.1.0_vbox-20070620+IPAFont.iso HTTP (Ring Servers): http://www.ring.gr.jp/archives/linux/knoppix/iso/ Bittorrent: http://unit.aist.go.jp/itri/knoppix/vmknoppix/knoppix_v5.1.1CD_20070104_xen3.1.0_vbox-20070620+IPAFont.iso.torrent * x86_64 vesion File name: knoppix-x86_64-v5.1.1CD-20070620_xen3.1.0.iso MD5: c75400575d4a1806668c4035007a1a05 FTP: ftp://unit.aist.go.jp/itri/knoppix/iso/knoppix-x86_64-v5.1.1CD-20070620_xen3.1.0.iso HTTP (Ring Servers): http://www.ring.gr.jp/archives/linux/knoppix/iso/knoppix-x86_64-v5.1.1CD-20070620_xen3.1.0.iso Bittorrent: http://unit.aist.go.jp/itri/knoppix/vmknoppix/knoppix-x86_64-v5.1.1CD-20070620_xen3.1.0.iso.torrent = ISO file for HttpDisk with Win-QEMU and VMKnoppix = HttpDisk is a Windows driver to mount a ISO file on a HTTP server. http://www.acc.umu.se/~bosse/ http://www.acc.umu.se/~bosse/httpdisk-3.zip We made ISO file which includes ROM-able applications. The ISO file includes Win-QEMU and boots KNOPPIX without installation. The ISO file is used with Httpdisk or normal DVD-ROM. *** Current ontents * OpenOffice.org, FireFox, GIMP, 7-Zip, SumatraPDF, ClamWin, Putty, Sudoku, QEMU, etc Most applications depend on http://portableapps.com. The contribution is much appreciated. * ISO file of VMKNOPPIX Win-QEMU uses it to boot KNOPPIX. *** Usage * If you want to use with HttpDisk, please install it at first. Mount the ISO file. Example Mount: httpdisk /mount 0 http://***/httpdisk20070621.iso /cd f: Example Unmount: httpdisk /umount f: We prepared some sites for HttpDisk in US and EU. The bandwidth of HttpDisk depends on network latency. Please select nearest one. US: United States of Amercia http://aist-midphase.com/archives/linux/oscircular/httpdisk/httpdisk20070621.iso http://aist-starlogic.com/archives/linux/oscircular/httpdisk/httpdisk20070621.iso http://www.aist-omnis.com/archives/linux/oscircular/httpdisk/httpdisk20070621.iso EU: Europian Union http://aist-knoppix-37.com/archives/linux/oscircular/httpdisk/httpdisk20070621.iso http://www.aist-nodo50.org/archives/linux/oscircular/httpdisk/httpdisk20070621.iso http://aist-easyspace.com/archives/linux/oscircular/httpdisk/httpdisk20070621.iso # The sites are for HttpDisk. Please download by bittorrent or other sites, if you want to whole ISO file. * If you want to use applications from a DVD-ROM, please burn the ISO image. * To run
[Qemu-devel] KQEMU causing guest to crash?
Hello all. When I attempt to boot the linux image from the download section, I get as far as Freeing unused memory before the guest os crashes, leaving me with this in my dmesg logs: 0PAX: suspicious general protection fault: [#4] Modules linked in: kqemu nvidia(P) CPU:0 EIP:0060:[00770297]Tainted: P VLI EFLAGS: 00210046 (2.6.19.2 #3) eax: 1b6de001 ebx: e2584000 ecx: edx: ddd7b5b0 esi: edi: ebp: 00200286 esp: d7913ee8 ds: 0068 es: 0068 ss: 0068 Process qemu (pid: 636, ti=d7912000 task=d12f2ab0 task.ti=d7912000) Stack: e2584000 00066c01 d12f2ab0 d948d900 d12f2ab0 e256c014 00200086 0033 e2584120 cfffd420 0007 e2584000 0076e1cf e2584000 0068 037f 0020 Call Trace: [0076e1cf] 0 [0076e0d0] 0 === Code: 84 83 ac 00 00 00 8b 10 8b 48 04 89 8b 94 00 00 00 89 93 90 00 00 00 8b 8b 9c 00 00 00 8b 93 98 00 00 00 89 48 04 89 10 89 1c 24 ff 54 24 20 31 c0 8b 93 88 00 00 00 80 bb 50 02 00 00 03 0f 94 EIP: [00770297] SS:ESP 0068:d7913ee8 I am using Linux 2.6.19.2 as the host os on an x86 machine. Does anyone know what is wrong? -- Make the most out of every dollar. Click here to find websites and services to help invest wisely. http://tagline.hushmail.com/fc/Ioyw6h4dPQr7yBTm5B6wECsGmjahrza96Ml2d3ZqXhcFx7ck59tioz/
[Qemu-devel] sh4: more patches
Hi everyone, Here comes a few more patches for the sh4 emulator. The should be applied on top of the patches that I posted a few weeks ago: http://www.mail-archive.com/qemu-devel@nongnu.org/msg10830.html Good news is that the user space emulator is in a much better shape now - with all the patches applied I'm successfully running a static busybox binary compiled for sh4 using qemu-sh4. The method used to locate emulation bugs may be of value for other fellow qemu hackers. I've written a small gdb script that single steps in an endless loop dumping registers between each instruction. Then I've used this script on both real target hardware (using gdbserver) and using the gdbstub provided by qemu. Finally the traces have been compared. I have more patches for this if anyone is interested... The patches attached in this email contain the following fixes: - sh4: Emulate more fpu opcodes - sh4: Swap word order when accessing double floats - sh4: Document FPSCR usage - sh4: Ignore PR flag in FPSCR when performing fmov - sh4: Use DREG() instead of XREG() wherever possible Could someone please comment or commit? =) Thank you! / magnus qemu-cvs_20070611-sh4-fpu-ops.patch Description: Binary data qemu-cvs_20070611-sh4-fpu-word-order.patch Description: Binary data qemu-cvs_20070507-sh4-fpu-fpscr-comments.patch Description: Binary data qemu-cvs_20070622-sh4-fpu-fmov-ignore-fpscr-pr.patch Description: Binary data qemu-cvs_20070508-sh4-dreg-fixes.patch Description: Binary data
[Qemu-devel] qemu qemu-doc.texi vl.c hw/usb-hid.c hw/usb.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/06/22 08:16:00 Modified files: . : qemu-doc.texi vl.c hw : usb-hid.c usb.h Log message: Add USB HID keyboard. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.150r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.308r2=1.309 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-hid.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb.h?cvsroot=qemur1=1.15r2=1.16
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/06/22 08:23:44 Modified files: . : vl.c Log message: Use HAS_ARG instead of numeric value (patch by Balazs Attila-Mihaly). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.309r2=1.310
[Qemu-devel] qemu/target-sh4 cpu.h exec.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 10:11:48 Modified files: target-sh4 : cpu.h exec.h Log message: Add missing cpu_halted function, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/cpu.h?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/exec.h?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] qemu/linux-user elfload.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 10:13:52 Modified files: linux-user : elfload.c Log message: Setup stack properly, fixes wrong argc value problem, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.42r2=1.43
[Qemu-devel] qemu/linux-user syscall_defs.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 10:15:10 Modified files: linux-user : syscall_defs.h Log message: Use correct data structures for stat syscalls, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemur1=1.34r2=1.35
[Qemu-devel] qemu/target-sh4 cpu.h op.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 11:12:02 Modified files: target-sh4 : cpu.h op.c translate.c Log message: Emulate more fpu opcodes, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/cpu.h?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.10r2=1.11
Re: [Qemu-devel] sh4: more patches
Magnus Damm wrote: Hi everyone, Here comes a few more patches for the sh4 emulator. The should be applied on top of the patches that I posted a few weeks ago: http://www.mail-archive.com/qemu-devel@nongnu.org/msg10830.html Good news is that the user space emulator is in a much better shape now - with all the patches applied I'm successfully running a static busybox binary compiled for sh4 using qemu-sh4. The method used to locate emulation bugs may be of value for other fellow qemu hackers. I've written a small gdb script that single steps in an endless loop dumping registers between each instruction. Then I've used this script on both real target hardware (using gdbserver) and using the gdbstub provided by qemu. Finally the traces have been compared. I have more patches for this if anyone is interested... The patches attached in this email contain the following fixes: - sh4: Emulate more fpu opcodes - sh4: Swap word order when accessing double floats Doesn't this one also depend on the host endianness? Thiemo
[Qemu-devel] qemu/target-mips op.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 11:50:17 Modified files: target-mips: op.c Log message: Fix write to K0 bits in Config0, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.65r2=1.66
[Qemu-devel] qemu/target-sh4 translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 11:43:08 Modified files: target-sh4 : translate.c Log message: Use DREG() instead of XREG() wherever possible, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.11r2=1.12
[Qemu-devel] qemu/target-sh4 translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 11:44:41 Modified files: target-sh4 : translate.c Log message: Document FPSCR usage, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu/target-sh4 translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 11:47:05 Modified files: target-sh4 : translate.c Log message: Ignore PR flag in FPSCR when performing fmov, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.13r2=1.14
Re: [Qemu-devel] QEMU License and proprietary hardware
On Thursday 21 June 2007 17:33, M. Warner Losh wrote: The GPL only has as much force of law as copyright law gives it, and in order to be applicable, the work in question must somehow rely on the GPL'd work. The somehow here is an interesting legal question that hasn't been well settled. And copyright law by default grants you no rights to modify or copy Qemu at all. The ONLY way you can get permission to copy or modify Qemu is to agree to the GPL in its entirety-- which does not restrict itself to merely derivative works, but covers all linking. (note: obvious the copyright holder(s) can make exceptions to this rule) IANAL either, but as much as I have to debate this I might as well be
Re: [Qemu-devel] QEMU License and proprietary hardware
On Friday 22 June 2007 00:34, Balazs Attila-Mihaly (Cd-MaN) wrote: I must prefix this with the fact that IANAL, but as I understand it, you must release the source code only if you distribute that modified system (with GPL v2). That is, if you use this system internally in you company, you don't have to provide your modifications. But if you, for example, provide your clients with the modified version, you have the obligation to provide them (your clients, not the Qemu community in general) also with the complete source code, after which they have the liberty to redistribute the source code under the GPL. Correct. One solution would be (again, IANAL, so please check with a real lawyer :D), The solution would be to comply with the GPL and release the code. :) is to create an interface to the code you wish to include and put the proprietary code in a dynamically linked library which exposes this interface. In this case IMHO you have to provide only the code which implements the interface in Qemu and loads the shared library, and you would have no obligation regarding the code in the shared library. The GPL is viral. A derivative-work wrapper would be under the full GPL terms and could not link out to a proprietary library either. While there are legal loopholes in the GPL, this is not one of them. (and no, I will not provide any more info on the loopholes I am aware of)
[Qemu-devel] shm problem
Hi, when using mmap with qemu-i386 on x86_64 it's quite simple to get 32-bit pointers back (using the MAP_32BIT flag, thanks to Kirill for the patch). I'm currently in the need for shared memory though, so I need shmat() to return something within the lower 31 Bits as well. shmget(0x56a4d5, 488, IPC_CREAT|0660) = 11075627 shmat(11075627, 0, 0) = 0x2b4ceb29e000 Does anyone have an idea how to get around this and force shmat to return something a 32-bit target can handle? In the end it only calls mmap too... Thanks, Alex
[Qemu-devel] Re: kqemu-1.3.0pre11 hangs system
--- Hugo Vanwoerkom [EMAIL PROTECTED] wrote: Hi, I am running Debian Sid and installed its qemu (0.9.0-2) package. Debian Sid has a problem: it's kqemu package is outdated, since it depends upon its 2.6.18 kernel, which is no longer available. So I compiled/installed kqemu-1.3.0pre11 instead on Debian's 2.6.21-1-k7. That all went uneventful. But booting XP completely hangs the system: it stops every clock/applet and needs the red button. W/o kqemu I can boot XP fine and get the message that kqemu is not available. I posted this a while ago and nobody responded. I found out what the problem is: If you use Debian's 2.6.21 kernel and modify it to turn *off* paravirtualization (to be able to use the nvidia closed source driver) and compile kqemu with that, qemu hangs solid on start. If you instead leave the kernel alone and modify the nvidia driver installation and Debian's kbuild-2.6.21 then everything is OK. Just for the record. Regards, Hugo Yahoo! Mail has very limited reply options. You can top-post or bottom-post and that's it! Hugo Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
Re: [Qemu-devel] QEMU License and proprietary hardware
From: Luke -Jr [EMAIL PROTECTED] Subject: Re: [Qemu-devel] QEMU License and proprietary hardware Date: Fri, 22 Jun 2007 10:18:01 -0500 On Thursday 21 June 2007 17:33, M. Warner Losh wrote: The GPL only has as much force of law as copyright law gives it, and in order to be applicable, the work in question must somehow rely on the GPL'd work. The somehow here is an interesting legal question that hasn't been well settled. And copyright law by default grants you no rights to modify or copy Qemu at all. The ONLY way you can get permission to copy or modify Qemu is to agree to the GPL in its entirety-- which does not restrict itself to merely derivative works, but covers all linking. (note: obvious the copyright holder(s) can make exceptions to this rule) Actually, the GPL does only apply to derived works, and it plainly says so: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law Linking typically is what makes a derived work, but not necessary. It is just the shade of grey that most people use as a rule of thumb. If you do not have a derived work, then you can use and distribute your work as you see fit, without the GPL restrictions. While the GPL is viral, it is only viral to the extent that the new work is derivative of the GPL'd work. This is why, for example, running my proprietary program on a Linux box doesn't mean my proprietary program is covered under the GPL. Although it uses the kernel, and in a very real sense the kernel links into the program due to address space mapping for system calls and the like, this isn't enough to make my program a derivative work. So it isn't 'black' vs 'white' but more of a 'this shade of grey is more white than black' or vice versa. I can make fair use use of GPL'd software with no restrictions what-so-ever so long as that use falls within 'fair use' as defined by copyright law. I can also use GPL'd code that doesn't quaify for copyright protection (as is the case if it lacks a creative element, is the only possible way to do something, etc). However, those exceptions tend to be rather specialized and limited. This isn't just GPL, btw, but any creative work. It is at the heart of the SCO case because SCO is claiming ~500 lines of Linux infringe on its copyright rights (to grossly oversimplify). Much of IBM's defence rests on exceptions to copyright law. IANAL either, but as much as I have to debate this I might as well be It is amaizing how many people get this wrong. It is subtle, and there's much misinformation circulating. I've had to do a lot of research in this area because of my involvement in FreeBSD's core team and the licensing issues that come up there... Warner
Re: [Qemu-devel] QEMU License and proprietary hardware
On Friday 22 June 2007 11:07, you wrote: On Thursday 21 June 2007 17:33, M. Warner Losh wrote: The GPL only has as much force of law as copyright law gives it, and in order to be applicable, the work in question must somehow rely on the GPL'd work. The somehow here is an interesting legal question that hasn't been well settled. And copyright law by default grants you no rights to modify or copy Qemu at all. The ONLY way you can get permission to copy or modify Qemu is to agree to the GPL in its entirety-- which does not restrict itself to merely derivative works, but covers all linking. (note: obvious the copyright holder(s) can make exceptions to this rule) Actually, the GPL does only apply to derived works, and it plainly says so: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law Linking typically is what makes a derived work, but not necessary. It is just the shade of grey that most people use as a rule of thumb. That's merely the definition of Program as used in the license. Read all the requirements, not just definitions... If you do not have a derived work, then you can use and distribute your work as you see fit, without the GPL restrictions. While the GPL is viral, it is only viral to the extent that the new work is derivative of the GPL'd work. This is why, for example, running my proprietary program on a Linux box doesn't mean my proprietary program is covered under the GPL. Although it uses the kernel, and in a very real sense the kernel links into the program due to address space mapping for system calls and the like, this isn't enough to make my program a derivative work. So it isn't 'black' vs 'white' but more of a 'this shade of grey is more white than black' or vice versa. The kernel contains exceptions for userland code. If it didn't, you would be unable to distribute your program alongside Linux. I can make fair use use of GPL'd software with no restrictions what-so-ever so long as that use falls within 'fair use' as defined by copyright law. I can also use GPL'd code that doesn't quaify for copyright protection (as is the case if it lacks a creative element, is the only possible way to do something, etc). How does linking fit under fair use?
Re: [Qemu-devel] QEMU License and proprietary hardware
In message: [EMAIL PROTECTED] Luke -Jr [EMAIL PROTECTED] writes: : On Friday 22 June 2007 11:07, you wrote: : On Thursday 21 June 2007 17:33, M. Warner Losh wrote: :The GPL only has as much force of law as copyright law gives it, and in :order to be applicable, the work in question must somehow rely on the :GPL'd work. The somehow here is an interesting legal question that :hasn't been well settled. : : And copyright law by default grants you no rights to modify or copy Qemu : at all. The ONLY way you can get permission to copy or modify Qemu is to : agree to the GPL in its entirety-- which does not restrict itself to : merely derivative works, but covers all linking. (note: obvious the : copyright holder(s) can make exceptions to this rule) : : Actually, the GPL does only apply to derived works, and it plainly : says so: : The Program, below, refers to any such program or work, and : a work based on the Program means either the Program or any : derivative work under copyright law : Linking typically is what makes a derived work, but not necessary. It : is just the shade of grey that most people use as a rule of thumb. : : That's merely the definition of Program as used in the : license. Read all the requirements, not just definitions... The definition is what is controlling here. IF it is a derived work THEN you must do X. If it is not a derived work, then you may do as you see fit. If what you did somehow wasn't a derivative work, then the there's no legal basis for forcing compliance with a license. This is exactly what SCO is trying to do right now with its IBM case. : If you do not have a derived work, then you can use and distribute : your work as you see fit, without the GPL restrictions. While the GPL : is viral, it is only viral to the extent that the new work is : derivative of the GPL'd work. This is why, for example, running my : proprietary program on a Linux box doesn't mean my proprietary program : is covered under the GPL. Although it uses the kernel, and in a very : real sense the kernel links into the program due to address space : mapping for system calls and the like, this isn't enough to make my : program a derivative work. So it isn't 'black' vs 'white' but more of : a 'this shade of grey is more white than black' or vice versa. : : The kernel contains exceptions for userland code. If it didn't, you would be : unable to distribute your program alongside Linux. Even if it didn't, you would be able to. Running a program on a kernel does not create a derivative work. I believe there is even case law on this. IIRC, there were cases with IBM and third parties providing software for mainframes that settled this, but I don't have the time to do an Internet search here. It is unclear for the Linux kernel if the 'end run' people do with loadable modules is a legal way to avoid source distribution. The FSF doesn't think so. Linus has said he's cool with it, but absent a statement from all the copyright holders of code in the Linux kernel, the issue is at best murky. It is unclear if the original poster tried to do a binary-only module with QEMU if he'd be in compliance or not (since the end user does the actual linking). : I can make fair use use of GPL'd software with no restrictions : what-so-ever so long as that use falls within 'fair use' as defined by : copyright law. I can also use GPL'd code that doesn't quaify for : copyright protection (as is the case if it lacks a creative element, : is the only possible way to do something, etc). : : How does linking fit under fair use? Again, this is another example of how the GPL isn't absolute. There is case law in reverse engineering cases for game consoles where it was held to be fair use to copy the ROMs into memory for the purpose of reverse engineering them. There may be other examples where linking, or linking-like activities are fair use. The biggest one being when the original post links in his proprietary module to QEMU. That's definitely fair use. Distributing the results may or may not be legal, depending on how the linking is done and a bunch of other factors. Warner
Re: [Qemu-devel] QEMU License and proprietary hardware
On Friday 22 June 2007 11:46, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Luke -Jr [EMAIL PROTECTED] writes: : On Friday 22 June 2007 11:07, you wrote: : On Thursday 21 June 2007 17:33, M. Warner Losh wrote: :The GPL only has as much force of law as copyright law gives it, :and in order to be applicable, the work in question must somehow :rely on the GPL'd work. The somehow here is an interesting legal :question that hasn't been well settled. : : And copyright law by default grants you no rights to modify or copy : Qemu at all. The ONLY way you can get permission to copy or modify : Qemu is to agree to the GPL in its entirety-- which does not restrict : itself to merely derivative works, but covers all linking. (note: : obvious the copyright holder(s) can make exceptions to this rule) : : Actually, the GPL does only apply to derived works, and it plainly : says so: :The Program, below, refers to any such program or work, and :a work based on the Program means either the Program or any :derivative work under copyright law : Linking typically is what makes a derived work, but not necessary. It : is just the shade of grey that most people use as a rule of thumb. : : That's merely the definition of Program as used in the : license. Read all the requirements, not just definitions... The definition is what is controlling here. IF it is a derived work THEN you must do X. If it is not a derived work, then you may do as you see fit. If what you did somehow wasn't a derivative work, then the there's no legal basis for forcing compliance with a license. This is exactly what SCO is trying to do right now with its IBM case. Unless you modify or distribute the work. These acts are illegal without compliance with the license. : If you do not have a derived work, then you can use and distribute : your work as you see fit, without the GPL restrictions. While the GPL : is viral, it is only viral to the extent that the new work is : derivative of the GPL'd work. This is why, for example, running my : proprietary program on a Linux box doesn't mean my proprietary program : is covered under the GPL. Although it uses the kernel, and in a very : real sense the kernel links into the program due to address space : mapping for system calls and the like, this isn't enough to make my : program a derivative work. So it isn't 'black' vs 'white' but more of : a 'this shade of grey is more white than black' or vice versa. : : The kernel contains exceptions for userland code. If it didn't, you would : be unable to distribute your program alongside Linux. Even if it didn't, you would be able to. Running a program on a kernel does not create a derivative work. I believe there is even case law on this. IIRC, there were cases with IBM and third parties providing software for mainframes that settled this, but I don't have the time to do an Internet search here. I bet those cases weren't distributing the kernel along with their software, were they? It is unclear for the Linux kernel if the 'end run' people do with loadable modules is a legal way to avoid source distribution. The FSF doesn't think so. Linus has said he's cool with it, but absent a statement from all the copyright holders of code in the Linux kernel, the issue is at best murky. It is unclear if the original poster tried to do a binary-only module with QEMU if he'd be in compliance or not (since the end user does the actual linking). It is undisputed that it would be in violation if the kernel was distributed with the modules. The GPL is clear that mere use (end user) is always allowed. It is also fairly clear (the opinions of many kernel developers and IP lawyers) that proprietary modules for Linux are illegal to distribute. As with all copyright violations, however, the liability is on the distributor's end, so the end user is again not liable for the download either.
Re: [Qemu-devel] QEMU License and proprietary hardware
Hi, On Fri, 22 Jun 2007, Luke -Jr wrote: On Friday 22 June 2007 11:46, M. Warner Losh wrote: If what you did somehow wasn't a derivative work, then the there's no legal basis for forcing compliance with a license. Unless you modify or distribute the work. These acts are illegal without compliance with the license. No. If what you did was not a derivative work, then it was no derivative work, then it was no derivative work. So if you changed a GPL program, and distribute that, you have to license these changes with the same license. If at the same time you make something original, which is not derived from the GPLed program, then you are as free as a bird to sh*t on the GPL with regards to your original work. You can choose whatever license, if any. What you throw about here, Luke, is FUD. The GPL is only insofar viral as you cannot take something GPLed and just relicense it at will. Not even when you modify it. However, writing a virtual device that just happens to be dynamically linkable to QEmu, but might just as well be linked to VMWare, is fine. This virtual device is clearly _not_ derived from QEmu. You can do something like that easily, by implementing a clean interface for QEmu, which allows you to runtime link with such a standalone virtual device. A couple of people would even thank you for that. Besides, QEmu's core is LGPL. Not GPL. All this discussion is moot though. If you're not a lawyer, you should not behave like one, and respect the wishes of the authors for a change. It is undisputed that it would be in violation if the kernel was distributed with the modules. Nope. It is not undisputed. The GPL is clear that mere use (end user) is always allowed. That's right. It is also fairly clear (the opinions of many kernel developers and IP lawyers) that proprietary modules for Linux are illegal to distribute. Nope. Not at all. I'd rather have your virtual device open sourced, but if you cannot do that, I'd rather have it closed-source, than not at all. And please stop this FUD about the GPL being viral and stuff. Ciao, Dscho
Re: [Qemu-devel] QEMU License and proprietary hardware
On Jun 22, 2007, at 10:11 AM, Luke -Jr wrote: On Friday 22 June 2007 11:46, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Luke -Jr [EMAIL PROTECTED] writes: : On Friday 22 June 2007 11:07, you wrote: : On Thursday 21 June 2007 17:33, M. Warner Losh wrote: :The GPL only has as much force of law as copyright law gives it, :and in order to be applicable, the work in question must somehow :rely on the GPL'd work. The somehow here is an interesting legal :question that hasn't been well settled. : : And copyright law by default grants you no rights to modify or copy : Qemu at all. The ONLY way you can get permission to copy or modify : Qemu is to agree to the GPL in its entirety-- which does not restrict : itself to merely derivative works, but covers all linking. (note: : obvious the copyright holder(s) can make exceptions to this rule) : : Actually, the GPL does only apply to derived works, and it plainly : says so: : The Program, below, refers to any such program or work, and : a work based on the Program means either the Program or any : derivative work under copyright law : Linking typically is what makes a derived work, but not necessary. It : is just the shade of grey that most people use as a rule of thumb. : : That's merely the definition of Program as used in the : license. Read all the requirements, not just definitions... The definition is what is controlling here. IF it is a derived work THEN you must do X. If it is not a derived work, then you may do as you see fit. If what you did somehow wasn't a derivative work, then the there's no legal basis for forcing compliance with a license. This is exactly what SCO is trying to do right now with its IBM case. Unless you modify or distribute the work. These acts are illegal without compliance with the license. : If you do not have a derived work, then you can use and distribute : your work as you see fit, without the GPL restrictions. While the GPL : is viral, it is only viral to the extent that the new work is : derivative of the GPL'd work. This is why, for example, running my : proprietary program on a Linux box doesn't mean my proprietary program : is covered under the GPL. Although it uses the kernel, and in a very : real sense the kernel links into the program due to address space : mapping for system calls and the like, this isn't enough to make my : program a derivative work. So it isn't 'black' vs 'white' but more of : a 'this shade of grey is more white than black' or vice versa. : : The kernel contains exceptions for userland code. If it didn't, you would : be unable to distribute your program alongside Linux. Even if it didn't, you would be able to. Running a program on a kernel does not create a derivative work. I believe there is even case law on this. IIRC, there were cases with IBM and third parties providing software for mainframes that settled this, but I don't have the time to do an Internet search here. I bet those cases weren't distributing the kernel along with their software, were they? It is unclear for the Linux kernel if the 'end run' people do with loadable modules is a legal way to avoid source distribution. The FSF doesn't think so. Linus has said he's cool with it, but absent a statement from all the copyright holders of code in the Linux kernel, the issue is at best murky. It is unclear if the original poster tried to do a binary-only module with QEMU if he'd be in compliance or not (since the end user does the actual linking). It is undisputed that it would be in violation if the kernel was distributed with the modules. The GPL is clear that mere use (end user) is always allowed. It is also fairly clear (the opinions of many kernel developers and IP lawyers) that proprietary modules for Linux are illegal to distribute. As with all copyright violations, however, the liability is on the distributor's end, so the end user is again not liable for the download either. Definitions/terms of the GPL aside, here's what the QEMU license file says: The following points clarify the QEMU license: 1) QEMU as a whole is released under the GNU General Public License 2) Parts of QEMU have specific licenses which are compatible with the GNU General Public License. Hence each source file contains its own licensing information. In particular, the QEMU virtual CPU core library (libqemu.a) is released under the GNU Lesser General Public License. Many hardware device emulation sources are released under the BSD license. 3) QEMU is a trademark of Fabrice Bellard. If the original poster is able to do what he wants using only the BSD- licensed hardware device emulation and the LGPL-licensed libqemu, I believe that he is free to distribute a *dynamically linked* machine emulator without placing his new code under the GPL. However, he will have to be very careful
Re: [Qemu-devel] QEMU License and proprietary hardware
[[ This is my last post on this topic, as we're starting to get quite far afield from QEMU and I'm starting to repeat myself. Luke -Jr wants the last word, he can have it ]] In message: [EMAIL PROTECTED] Luke -Jr [EMAIL PROTECTED] writes: : On Friday 22 June 2007 11:46, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Luke -Jr [EMAIL PROTECTED] writes: : : On Friday 22 June 2007 11:07, you wrote: : : On Thursday 21 June 2007 17:33, M. Warner Losh wrote: : :The GPL only has as much force of law as copyright law gives it, : :and in order to be applicable, the work in question must somehow : :rely on the GPL'd work. The somehow here is an interesting legal : :question that hasn't been well settled. : : : : And copyright law by default grants you no rights to modify or copy : : Qemu at all. The ONLY way you can get permission to copy or modify : : Qemu is to agree to the GPL in its entirety-- which does not restrict : : itself to merely derivative works, but covers all linking. (note: : : obvious the copyright holder(s) can make exceptions to this rule) : : : : Actually, the GPL does only apply to derived works, and it plainly : : says so: : : The Program, below, refers to any such program or work, and : : a work based on the Program means either the Program or any : : derivative work under copyright law : : Linking typically is what makes a derived work, but not necessary. It : : is just the shade of grey that most people use as a rule of thumb. : : : : That's merely the definition of Program as used in the : : license. Read all the requirements, not just definitions... : : The definition is what is controlling here. IF it is a derived work : THEN you must do X. If it is not a derived work, then you may do as : you see fit. If what you did somehow wasn't a derivative work, then : the there's no legal basis for forcing compliance with a license. : This is exactly what SCO is trying to do right now with its IBM case. : : Unless you modify or distribute the work. These acts are illegal without : compliance with the license. Modifying the work may create a derivative work. If it does (and it usually does), then you are correct. If it does not for some reason, then the terms do not apply. : : If you do not have a derived work, then you can use and distribute : : your work as you see fit, without the GPL restrictions. While the GPL : : is viral, it is only viral to the extent that the new work is : : derivative of the GPL'd work. This is why, for example, running my : : proprietary program on a Linux box doesn't mean my proprietary program : : is covered under the GPL. Although it uses the kernel, and in a very : : real sense the kernel links into the program due to address space : : mapping for system calls and the like, this isn't enough to make my : : program a derivative work. So it isn't 'black' vs 'white' but more of : : a 'this shade of grey is more white than black' or vice versa. : : : : The kernel contains exceptions for userland code. If it didn't, you would : : be unable to distribute your program alongside Linux. : : Even if it didn't, you would be able to. Running a program on a : kernel does not create a derivative work. I believe there is even : case law on this. IIRC, there were cases with IBM and third parties : providing software for mainframes that settled this, but I don't have : the time to do an Internet search here. : : I bet those cases weren't distributing the kernel along with their software, : were they? They were, actually. The cases I'm thinking of had to do with VARs integrating their software and shipping the systems to end users. Similar, but not identical. : It is unclear for the Linux kernel if the 'end run' people do with : loadable modules is a legal way to avoid source distribution. The FSF : doesn't think so. Linus has said he's cool with it, but absent a : statement from all the copyright holders of code in the Linux kernel, : the issue is at best murky. It is unclear if the original poster : tried to do a binary-only module with QEMU if he'd be in compliance or : not (since the end user does the actual linking). : : It is undisputed that it would be in violation if the kernel was distributed : with the modules. It is not undisputed. Linus Torvalds doesn't hold that view, for example. All the wireless device makers today that are based on linux use binary-only modules for their wireless devices. Similar issues happen with NTFS write support in many of network attached storage devices. These devices are distributed with both the kernel and devices in the same flash. I've included some examples of divergent opinion within the Linux kernel community below. : The GPL is clear that mere use (end user) is always allowed. It is : also fairly clear (the opinions of many kernel
Re: [Qemu-devel] QEMU License and proprietary hardware
On Friday 22 June 2007 12:37, Johannes Schindelin wrote: If at the same time you make something original, which is not derived from the GPLed program, then you are as free as a bird to sh*t on the GPL with regards to your original work. You can choose whatever license, if any. Not if you want to distribute the GPL'd work, or anything derived from it. The GPL is only insofar viral as you cannot take something GPLed and just relicense it at will. Not even when you modify it. Then explain the difference between the LGPL and GPL. A license that preserves itself only is pointless without other terms. However, writing a virtual device that just happens to be dynamically linkable to QEmu, but might just as well be linked to VMWare, is fine. This virtual device is clearly _not_ derived from QEmu. That allows you to distribute the virtual device by itself, not alongside with Qemu. Besides, QEmu's core is LGPL. Not GPL. Good point, and makes this entire argument mostly irrelevant. It is undisputed that it would be in violation if the kernel was distributed with the modules. Nope. It is not undisputed. It is undisputed by anyone who has ever considered the issue as part of deciding whether or not to do it. It is also fairly clear (the opinions of many kernel developers and IP lawyers) that proprietary modules for Linux are illegal to distribute. Nope. Not at all. http://www.kroah.com/log/linux/ols_2006_keynote.html I'd rather have your virtual device open sourced, but if you cannot do that, I'd rather have it closed-source, than not at all. I would never buy software without source. Hopefully someday I can apply this to hardware as well.
Re: [Qemu-devel] QEMU License and proprietary hardware
Hi, On Fri, 22 Jun 2007, Luke -Jr wrote: On Friday 22 June 2007 12:37, Johannes Schindelin wrote: If at the same time you make something original, which is not derived from the GPLed program, then you are as free as a bird to sh*t on the GPL with regards to your original work. You can choose whatever license, if any. Not if you want to distribute the GPL'd work, or anything derived from it. You can distribute on the same medium, at the same time, two different programs, one GPL, the other not. No problem. None at all. The GPL is only insofar viral as you cannot take something GPLed and just relicense it at will. Not even when you modify it. Then explain the difference between the LGPL and GPL. A license that preserves itself only is pointless without other terms. No, it is not. However, writing a virtual device that just happens to be dynamically linkable to QEmu, but might just as well be linked to VMWare, is fine. This virtual device is clearly _not_ derived from QEmu. That allows you to distribute the virtual device by itself, not alongside with Qemu. To the contrary. You can distribute them both at the same time, under different conditions, much like you can distribute QEmu with parts GPL, parts LGPL, and parts BSD. Besides, QEmu's core is LGPL. Not GPL. Good point, and makes this entire argument mostly irrelevant. Not at all. If it was a derivative work of the LGPLed part, it would still have to be LGPLed. It is undisputed that it would be in violation if the kernel was distributed with the modules. Nope. It is not undisputed. It is undisputed by anyone who has ever considered the issue as part of deciding whether or not to do it. There are distributions which deliver closed source binary-only modules. Many LiveCDs for example. It is also fairly clear (the opinions of many kernel developers and IP lawyers) that proprietary modules for Linux are illegal to distribute. Nope. Not at all. http://www.kroah.com/log/linux/ols_2006_keynote.html That is Greg's opinion. There are others. Notably Linus'. I'd rather have your virtual device open sourced, but if you cannot do that, I'd rather have it closed-source, than not at all. I would never buy software without source. Hopefully someday I can apply this to hardware as well. That is your freedom. Frankly, I get really bored by the license discussions these days. Gone seem the days where you discussed code and algorithms on the mailing lists. Sigh. Ciao, Dscho
[Qemu-devel] qemu-i386 segfaults running hello world.
Problem: [EMAIL PROTECTED]:~/firmware/firmware$ build/temp-i686/hello Hello world! [EMAIL PROTECTED]:~/firmware/firmware$ qemu-i386 build/temp-i686/hello Segmentation fault (core dumped) This is on a cvs snapshot from 15 minutes ago. The hello world is a statically linked executable built against uClibc 0.9.29. It runs fine from the command line, but qemu application emulation goes boing. The executable is attached. Am I doing something wrong? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. hello Description: application/executable
[Qemu-devel] [PATCH] Implement ^W in readline.c
Hello
The patch below implements ^W (Ctrl+W) in readline.c, allowing it to be
used in the monitor.
Signed-off-by: Michael Hanselmann [EMAIL PROTECTED]
Greets,
Michael
---
Index: readline.c
===
RCS file: /sources/qemu/qemu/readline.c,v
retrieving revision 1.1
diff -u -b -B -r1.1 readline.c
--- readline.c 1 Aug 2004 21:52:19 - 1.1
+++ readline.c 22 Jun 2007 22:17:47 -
@@ -156,6 +156,45 @@
}
}
+static void term_backword(void)
+{
+int start;
+
+if (term_cmd_buf_index == 0 || term_cmd_buf_index term_cmd_buf_size) {
+return;
+}
+
+start = term_cmd_buf_index - 1;
+
+/* find first word (backwards) */
+while (start 0) {
+if (!isspace(term_cmd_buf[start])) {
+break;
+}
+
+--start;
+}
+
+/* find first space (backwards) */
+while (start 0) {
+if (isspace(term_cmd_buf[start])) {
+++start;
+break;
+}
+
+--start;
+}
+
+/* remove word */
+if (start term_cmd_buf_index) {
+memmove(term_cmd_buf + start,
+term_cmd_buf + term_cmd_buf_index,
+term_cmd_buf_size - term_cmd_buf_index);
+term_cmd_buf_size -= term_cmd_buf_index - start;
+term_cmd_buf_index = start;
+}
+}
+
static void term_bol(void)
{
term_cmd_buf_index = 0;
@@ -338,6 +377,10 @@
/* NOTE: readline_start can be called here */
term_readline_func(term_readline_opaque, term_cmd_buf);
break;
+case 23:
+/* ^W */
+term_backword();
+break;
case 27:
term_esc_state = IS_ESC;
break;
[Qemu-devel] [PATCH] Fix two typos
Hi,
The patch below, taken from the Debian package, fixes two typos:
- substract - subtract
- formating - formatting
Bye,
Aurelien
Index: monitor.c
===
RCS file: /sources/qemu/qemu/monitor.c,v
retrieving revision 1.73
diff -u -d -p -r1.73 monitor.c
--- monitor.c 24 May 2007 18:53:22 - 1.73
+++ monitor.c 22 Jun 2007 22:16:44 -
@@ -784,7 +784,7 @@ static const KeyDef key_defs[] = {
{ 0xb5, kp_divide },
{ 0x37, kp_multiply },
-{ 0x4a, kp_substract },
+{ 0x4a, kp_subtract },
{ 0x4e, kp_add },
{ 0x9c, kp_enter },
{ 0x53, kp_decimal },
Index: qemu-img.c
===
RCS file: /sources/qemu/qemu/qemu-img.c,v
retrieving revision 1.17
diff -u -d -p -r1.17 qemu-img.c
--- qemu-img.c 10 Feb 2007 22:59:40 - 1.17
+++ qemu-img.c 22 Jun 2007 22:16:44 -
@@ -297,7 +297,7 @@ static int img_create(int argc, char **a
drv = bdrv_find_format(fmt);
if (!drv)
error(Unknown file format '%s', fmt);
-printf(Formating '%s', fmt=%s,
+printf(Formatting '%s', fmt=%s,
filename, fmt);
if (encrypted)
printf(, encrypted);
Index: target-ppc/cpu.h
===
RCS file: /sources/qemu/qemu/target-ppc/cpu.h,v
retrieving revision 1.47
diff -u -d -p -r1.47 cpu.h
--- target-ppc/cpu.h3 Jun 2007 21:02:38 - 1.47
+++ target-ppc/cpu.h22 Jun 2007 22:16:45 -
@@ -1326,7 +1326,7 @@ enum {
EXCP_FP_ZX = 0x03, /* FP divide by zero*/
EXCP_FP_XX = 0x04, /* FP inexact */
EXCP_FP_VXNAN = 0x05, /* FP invalid SNaN op */
-EXCP_FP_VXISI = 0x06, /* FP invalid infinite substraction */
+EXCP_FP_VXISI = 0x06, /* FP invalid infinite subtraction */
EXCP_FP_VXIDI = 0x07, /* FP invalid infinite divide */
EXCP_FP_VXZDZ = 0x08, /* FP invalid zero divide */
EXCP_FP_VXIMZ = 0x09, /* FP invalid infinite * zero */
Index: target-ppc/op.c
===
RCS file: /sources/qemu/qemu/target-ppc/op.c,v
retrieving revision 1.36
diff -u -d -p -r1.36 op.c
--- target-ppc/op.c 24 Apr 2007 06:50:21 - 1.36
+++ target-ppc/op.c 22 Jun 2007 22:16:45 -
@@ -1025,7 +1025,7 @@ void OPPROTO op_nego_64 (void)
}
#endif
-/* substract from */
+/* subtract from */
PPC_OP(subf)
{
T0 = T1 - T0;
@@ -1058,7 +1058,7 @@ void OPPROTO op_check_subfo_64 (void)
}
#endif
-/* substract from carrying */
+/* subtract from carrying */
void OPPROTO op_check_subfc (void)
{
if (likely((uint32_t)T0 (uint32_t)T1)) {
@@ -1081,7 +1081,7 @@ void OPPROTO op_check_subfc_64 (void)
}
#endif
-/* substract from extended */
+/* subtract from extended */
void OPPROTO op_subfe (void)
{
do_subfe();
@@ -1096,7 +1096,7 @@ void OPPROTO op_subfe_64 (void)
}
#endif
-/* substract from immediate carrying */
+/* subtract from immediate carrying */
void OPPROTO op_subfic (void)
{
T0 = (int32_t)PARAM1 + ~T0 + 1;
@@ -1121,7 +1121,7 @@ void OPPROTO op_subfic_64 (void)
}
#endif
-/* substract from minus one extended */
+/* subtract from minus one extended */
void OPPROTO op_subfme (void)
{
T0 = ~T0 + xer_ca - 1;
@@ -1154,7 +1154,7 @@ void OPPROTO op_subfmeo_64 (void)
}
#endif
-/* substract from zero extended */
+/* subtract from zero extended */
void OPPROTO op_subfze (void)
{
T1 = ~T0;
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] [PATCH] GNU/kFreeBSD support
Hi,
The patch below, taken from the Debian package, adds support
for GNU/kFreeBSD.
Bye,
Aurelien
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.145
diff -u -d -p -r1.145 configure
--- configure 26 May 2007 16:38:53 - 1.145
+++ configure 22 Jun 2007 22:16:44 -
@@ -112,6 +112,12 @@ OS_CFLAGS=-mno-cygwin
MINGW32*)
mingw32=yes
;;
+GNU/kFreeBSD)
+oss=yes
+if [ $cpu = i386 -o $cpu = x86_64 ] ; then
+kqemu=yes
+fi
+;;
FreeBSD)
bsd=yes
oss=yes
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.310
diff -u -d -p -r1.310 vl.c
--- vl.c22 Jun 2007 08:23:44 - 1.310
+++ vl.c22 Jun 2007 22:16:44 -
@@ -47,6 +47,8 @@
#ifndef __APPLE__
#include libutil.h
#endif
+#elif defined (__GLIBC__) defined (__FreeBSD_kernel__)
+#include freebsd/stdlib.h
#else
#ifndef __sun__
#include linux/if.h
@@ -3451,7 +3453,7 @@ static TAPState *net_tap_fd_init(VLANSta
return s;
}
-#ifdef _BSD
+#if defined (_BSD) || defined (__FreeBSD_kernel__)
static int tap_open(char *ifname, int ifname_size)
{
int fd;
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] [PATCH] Exit error code for -M ?
Hi, The patch below, taken from the Debian package, fixes the exit error code when the list of supported machine is requested (-M ?). asked Bye, Aurelien Index: vl.c === RCS file: /sources/qemu/qemu/vl.c,v retrieving revision 1.310 diff -u -d -p -r1.310 vl.c --- vl.c22 Jun 2007 08:23:44 - 1.310 +++ vl.c22 Jun 2007 22:16:44 - @@ -6705,7 +6707,7 @@ void help(void) #endif DEFAULT_GDBSTUB_PORT, /tmp/qemu.log); -exit(1); +exit(strcmp(optarg, ?)); } #define HAS_ARG 0x0001 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
Ok, it's a more fundamental problem: [EMAIL PROTECTED]:/sys$ qemu-i386 Segmentation fault (core dumped) Nothing to do with the program it's trying to run, it segfaults with no arguments. Is anybody else seeing this? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
[Qemu-devel] qemu/target-mips translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/22 23:50:20 Modified files: target-mips: translate_init.c Log message: Allow emulation of 32bit targets in the MIPS64 capable qemu version. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.15r2=1.16
[Qemu-devel] Netbsd/sparc seems to sort-of boot on the 20070622 CVS release
Not going to count my kittens before they scratch... -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] qemu-i386 segfaults running hello world.
On Friday 22 June 2007 19:13:19 Alexander Graf wrote:
Rob Landley wrote:
Ok, it's a more fundamental problem:
[EMAIL PROTECTED]:/sys$ qemu-i386
Segmentation fault (core dumped)
Nothing to do with the program it's trying to run, it segfaults with no
arguments.
Is anybody else seeing this?
Rob
[EMAIL PROTECTED]:/vm/qemu-devel/patches/qemu qemu-i386 ~/hello
Hello world!
Well it works for me. I usually see this segfault when trying to compile
qemu with a gcc4. Try gcc3 and everything should be fine.
It's using gcc-3.4. The one that comes with Ubuntu 7.04. (Or at
least ./configure said it had found gcc-3.4 during configuration, anyway.)
I ran the sucker under strace and it seems to be segfaulting right before it
calls main(). I stuck an exit(1) at the start of main and it doesn't get to
it, but it's after all the shared libraries are loaded:
mprotect(0xb7f3f000, 4096, PROT_READ) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_WRITE) = 0
mprotect(0x8000, 548864, PROT_READ|PROT_EXEC) = 0
munmap(0xb7f76000, 57255) = 0
set_tid_address(0xb7deca88) = 4338
sendto(-1210135920, umovestr: Input/output error
0xc, 3084914676,
MSG_DONTWAIT|MSG_CONFIRM|MSG_FIN|MSG_NOSIGNAL|MSG_MORE|0xb7de,
{sa_family=AF_DECnet, sa_data=\0\0\320=\0\0\r\0\0\0p\362\0\0},
3217384328) = 0 rt_sigaction(SIGRTMIN, {0xb7df13f0, [], SA_SIGINFO}, NULL,
8) = 0
rt_sigaction(SIGRT_1, {0xb7df1300, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys=Linux, node=triolith, ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Process 4338 detached
If I link int main() {} against -lm and -lrt I get the same set of calls up
through the first mprotect. (The next two mprotects are probably setting up
other segments like bss that an empty program doesn't have.) Then everything
up through the uname() is the same... And then it would call main.
Right now I'm commenting out various global variable initializations because
that's what comes to mind as stuff that runs right before main().
By the way, by commenting out this bit:
//const char interp[] __attribute__((section(.interp)))
= /lib/ld-linux.so.2;
I made it go from segmentation fault to illegal instruction as the reason
it dies. Which is weird because there's no non-x86 toolchain the path, this
is all stock Ubuntu stuff. But oh well...
Alex
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
