qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] in-kernel irqchip : split devices


From: Glauber Costa
Subject: Re: [Qemu-devel] [RFC] in-kernel irqchip : split devices
Date: Mon, 26 Oct 2009 17:27:21 +0100
User-agent: Jack Bauer

On Sun, Oct 25, 2009 at 12:26:51PM +0200, Avi Kivity wrote:
> On 10/14/2009 04:30 PM, Glauber Costa wrote:
>> Hello people,
>>
>> As I promised, I am sending a very brief PoC wrt split devices and in-kernel 
>> irqchip.
>> In this mail, I am including only the ioapic version for apreciation. I also 
>> have i8259,
>> and apic will take me a little bit more. This is just to try to bind the 
>> discussion to real
>> code.
>>
>>    
>
> I still can't say I like it.  The reset function is duplicated, the  
> state representation (which is an ABI) is gratuitously forked.
>
> You can't save/restore in-kernel irqchip and userspace irqchip, even  
> though where the code is located is an implementation detail.  While we  
> may not care much for the ioapic, it sets a bad precedent for vhost-net,  
> where we'd like to migrate from non-vhost-net hosts to vhost-net hosts  
> without the user noticing anything.
>
>> Note that we end up with a very slim representation of the device, and the 
>> code is much less
>> confusing, IMHO.
>>    
>
> You can always remove if statements by duplicating the code and pushing  
> the if one level upwards.  In total, there is more code, and it is more  
> confusing (since you need to deal with implementation details at a  
> higher level).
>

It pretty much depends on your definition of confusing.
Larger? yes, probably. It has a separate file, and doesn't matter how hard
we fight duplicates, some will persist.

But just the other day, I was on IRC with anthony, trying to draw some
conclusions about the behaviour of our ioapic. We went through it,
and it took us quite a while to determine what pieces of code were being
used, and what were not. This is pretty much what I mean by confusing.

With the approach we are proposing, things get much more straightforward
> -- 
> error compiling committee.c: too many arguments to function
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]