From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI Date: Sun, 11 Jan 2009 11:38:22 +0200 Message-ID: <4969BE0E.7070206@redhat.com> References: <1231411535-2461-1-git-send-email-sheng@linux.intel.com> <1231411535-2461-2-git-send-email-sheng@linux.intel.com> <496616E9.5040007@redhat.com> <200901091050.59817.sheng@linux.intel.com> <49679209.1030600@redhat.com> <20090110122806.GA27650@yukikaze> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Avi Kivity , Sheng Yang , Marcelo Tosatti , kvm@vger.kernel.org Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42495 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbZAKJiZ (ORCPT ); Sun, 11 Jan 2009 04:38:25 -0500 In-Reply-To: <20090110122806.GA27650@yukikaze> Sender: kvm-owner@vger.kernel.org List-ID: Sheng Yang wrote: > After reconsidering, I must say I prefer add/remove ioctls. > > About the code size, I don't think it would increase much. I've rewritten > the code twice, I think I know the difference is little. > :( sorry about that. > For the option 2 route table ioctl, we got a array from userspace, and would > convert it to linked list and keep it in kernel. That's a kind of must(I > don't think you would prefer use a array in kernel), and it's very direct. > Actually, eventually we'd want an array indexed by gsi. Each element would be a pointer to another array (one or two routing entries). Certainly we don't want to iterate a list which could hold several hundred interrupts for a large guest. It's okay to start with a linked list, but eventually we'll want something faster. > So, we have to insert/delete route entry for both. What's the real > difference we do it one by one or do it all at once. I don't think it is > much different on the code size. And it's indeed very clear and direct. > > Beside this, option 2 seems strange. Why should we handle this table in this > way when it won't result in significant code reduce. Insert/delete entry it > there, look up entry is also there, not many things changed. And it's not > that direct as option 1, which also can be a source of bugs. > > How do you think? > I'm not convinced. Please post your latest, and I will post a counter-proposal. -- error compiling committee.c: too many arguments to function