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 >
