Re: [Qemu-ppc] [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 6, 2012 at 3:42 AM, Alexander Graf <agraf@xxxxxxx> wrote:
>
> On 05.09.2012, at 15:38, Blue Swirl wrote:
>
>> On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
>>> Blue Swirl <blauwirbel@xxxxxxxxx> writes:
>>>
>>>> On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
>>>>> Avi Kivity <avi@xxxxxxxxxx> writes:
>>>>>
>>>>>> On 09/05/2012 12:00 AM, Anthony Liguori wrote:
>>>>>>>>
>>>>>>>> Why? The way this is being submitted I don't see why we should treat
>>>>>>>> Jan's patch any different from a patch by IBM or Samsung where we've
>>>>>>>> asked folks to fix the license to comply with what I thought was our new
>>>>>>>> policy (it does not even contain a from-x-on-GPLv2+ notice).
>>>>>>>
>>>>>>> Asking is one thing.  Requiring is another.
>>>>>>>
>>>>>>> I would prefer that people submitted GPLv2+, but I don't think it should
>>>>>>> be a hard requirement.  It means, among other things, that we cannot
>>>>>>> accept most code that originates from the Linux kernel.
>>>>>>
>>>>>> We could extend this to "require unless there is a reason to grant an
>>>>>> exception" if we wanted to (not saying I know whether we want to or
>>>>>> not).
>>>>>
>>>>> I don't want QEMU to be GPLv3.  I don't like the terms of the GPLv3.
>>>>>
>>>>> I don't mind GPLv2+, if people want to share code from QEMU in GPLv3
>>>>> projects, GPLv2+ enables that.
>>>>
>>>> The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that
>>>> QEMU could share code from GPLv3 projects, specifically latest
>>>> binutils. Reinventing a disassembler for ever growing x86 assembly is
>>>> no fun.
>>>
>>> But we can't share code with Linux (like for virtio).
>>
>> It's a tradeoff between reimplementing disassembler without using
>> binutils vs. reimplementing virtio without using Linux. Both have
>> their problems and both are growing areas. Disassembler is a bit
>> smaller and the basic function does not ever change.
>>
>>>
>>> Yes, the GPLv3 sucks and FSF screwed up massively not making it v2
>>> compatible.
>>
>> I sort of agree. They had their reasons, of course. Too bad binutils
>> licensing is fully controlled by FSF, for us it would be enough if
>> they had some sort of dual licensing scheme (GPLv3 + BSD for example)
>> in place.
>
> What do the BSD guys do here? They want to have a disassembler too that works across all different sorts of architectures, no?

There's at least GDB and DDD. The DDB kernel debugger contains a
disassembler for several architectures:
http://fxr.watson.org/fxr/ident?v=NETBSD&i=db_disasm

At least cris, lm32, microblaze, unicore32 and s390x are still missing
and I don't know if sh3 equals sh4. For some of those, maybe current
code from old binutils will be good enough forever.

It looks like the most recent change for x86 is from 2009 and there's
no support for even MMX so it does not look very potential way to
handle the x86 instruction set growth.

>
>
> Alex
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux