Re: Extending virtio_console to support multiple ports

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

 



On (Mon) Aug 31 2009 [10:56:27], Anthony Liguori wrote:
> Amit Shah wrote:
>> On (Mon) Aug 31 2009 [09:21:13], Anthony Liguori wrote:
>>   
>>> Amit Shah wrote:
>>>     
>>>> Can you please explain your rationale for being so rigid about merging
>>>> the two drivers?
>>>>         
>>> Because they do the same thing.  I'm not going to constantly rehash   
>>> this.  It's been explained multiple times.
>>>     
>>
>> It hardly looks like the same thing each passing day.
>>   
>
> That's BS.  The very first time you posted, you received the same  
> feedback from both Paul and I.  See  
> http://article.gmane.org/gmane.comp.emulators.qemu/44778.  That was back  
> in June.  You've consistently received the same feedback both on the ML  
> and in private.

I'm just saying they all start looking the same.

>> We're ending up having to compromise on the performance or functionality
>> or simplicity the devices just because of this restriction.
>>   
>
> This is _not_ a high performance device and there so far has been no  
> functionality impact.  I don't understand why you keep dragging your  
> feet about this.  It's very simple, if you post a functional set of  
> patches for a converged virtio-console driver, we'll merge it.  If you  

I have already posted them and have received no feedback about the
patches since. Let me add another request here for you to review them.

> keep arguing about having a separate virtio-serial driver, it's not  
> going to get merged.  I don't know how to be more clear than this.

I'm not at all arguing for a separate virtio-serial driver. Please note
the difference in what I'm asking for: I'm just asking for a good
justification for the merging of the two since it just makes both the
drivers not simple and also introduces dependencies on code outside our
control.

>>> If there are implementation issues within the Linux drivers because 
>>> of  peculiarities of hvc then hvc needs to be fixed.  It has nothing 
>>> to do  with the driver ABI which is what qemu cares about.
>>>     
>>
>> I'd welcome that effort as well. But we all know that's not going to
>> happen anytime soon.
>>   
>
> That is not a justification to add a new device in QEMU.  If we add a  
> new device everytime we encounter a less than ideal interface within a  
> guest, we're going to end up having hundreds of devices.

I just find this argument funny.

		Amit
--
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