Yes, license is a big problem. And I'm sorry to let you and Brandon know that Luvalley is currently using KVM's code. And I think it's hard and unnecessary to write the virtualization code from scratch. Do you think so?
Best regards, Xiaodong 2011/1/9 Juergen Lock <n...@jelal.kn-bremen.de>: > On Sun, Jan 09, 2011 at 12:33:59AM -0600, Brandon Gooch wrote: >> On Sun, Jan 9, 2011 at 12:01 AM, Xiaodong Yi <xdong...@gmail.com> wrote: >> > Hi, >> > >> > I confirm that I no longer have time for Luvalley. However, I will be >> > extreemly happy if anybody is willing to take over from me. >> > Especially, I quite agree to customize Luvalley for FreeBSD, through >> > it supports all kinds of Dom0 OSes. Howerver, I hope that the LIGHT >> > architecture of Luvalley could be kept. Maybe it is useful to patch >> > dom0 FreeBSD kernel (especially for interrupt handling), but it should >> > not be very complex. Part of the code comes from KVM, and I suggest to >> > keep flying with KVM to make sure that guest VMs work well. >> >> I believe that if serious effort were to be put forward by the FreeBSD >> developers to further develop the code, the result would need to be >> GPL and Linux free (or VERY close to it). This is an area of >> contention within the FreeBSD developer and user community, so it >> would need to be addressed. As the developer of Luvalley, do you have >> the ability to re-license the code using a BSD license? >> >> Are there too many technical issues with the code to do this? Juergen >> mentioned that bits of the code are based on (or pulled directly >> from?) Linux KVM. That probably wouldn't fly here... >> >> > Luvalley does boot and run on bare hardware. But it does not taint >> > dom0 FreeBSD. Although the `non-root' mode dom0 FreeBSD kernel has >> > direct access to BIOS and hardware, Luvalley tries hard to coordinate >> > with it. For example, Luvalley traps the BIOS calls from the FreeBSD >> > kernel to report the modified E820 table. Another example is that >> > Luvalley uses NMI as the IPI interrupt to avoid conflict with BSD >> > kernel. And I also believe that simple patches could work if some >> > corners of FreeBSD kernel are tainted. >> > >> > Regards, and looking forward to the following news ... >> > >> > Xiaodong >> >> As am I... >> >> Thanks for chiming in Xiaodong! > > Actually with `tainting' the FreeBSD kernel I meant causing it to be > affected by the gpl and its requirements. So if someone were to ship > e.g. an appliance that uses Luvalley and a modified FreeBSD kernel he > would only have to provide sourcecode of Luvalley and the userland > Luvalley version of qemu-kvm, not of his FreeBSD kernel modifications, > or of other (non-gpl) userland apps for that matter. > > But again, IANAL. :) > > Cheers, > Juergen (also hoping Luvalley will have a future...) > _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
