From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4mGR-00040p-Ue for qemu-devel@nongnu.org; Mon, 05 Mar 2012 23:44:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4mGQ-0000gk-5f for qemu-devel@nongnu.org; Mon, 05 Mar 2012 23:44:43 -0500 Received: from usrksweb02.endace.com ([174.143.168.194]:55335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4mGP-0000g5-VG for qemu-devel@nongnu.org; Mon, 05 Mar 2012 23:44:42 -0500 Message-ID: <4F559624.6000904@endace.com> Date: Tue, 6 Mar 2012 17:44:20 +1300 From: Alexey Korolev MIME-Version: 1.0 References: <1330581043.29508.61.camel@nzhmlwks0057.ad.endace.com> <20120304194030.GJ29291@morn.localdomain> <4F548D15.5000609@redhat.com> <20120305134910.GB9697@morn.localdomain> In-Reply-To: <20120305134910.GB9697@morn.localdomain> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: mst@redhat.com, sfd@endace.com, seabios@seabios.org, qemu-devel@nongnu.org, Gerd Hoffmann , avi@redhat.com On 06/03/12 02:49, Kevin O'Connor wrote: > On Mon, Mar 05, 2012 at 10:53:25AM +0100, Gerd Hoffmann wrote: >>> Given the churn in this area, I don't want to commit patches that do >>> wholesale code replacement. I'd prefer to see each patch >>> independently add some functionality and perform its related cleanup. >> Hardly doable, the algorithms are very different. > I don't think that the algorithms are that different, and I don't > think sending incremental patches is too difficult. > > Looking at Alexey's patches, it seems that "struct pci_region_entry" > == "struct pci_device.bars" and "struct pci_region" == "struct > pci_bus.r". The pci_region_entry structs are dynamically allocated > and put on lists, and the count/base arrays are replaced with list > traversals. The core multi-pass algorithm which finds the devices, > extracts the bar info, determines the required bus sizing, and then > assigns the bars does not appear to be fundamentally different. I > don't see why the data structures can't be converted in a series of > incremental patches. The only significant algo change (replacement of > count/base arrays with list traversal) should be a relatively simple > reviewable patch once the data structures have been modified. Right, there is no point to make big functional changes, since existing algorithms are same. Note: pci_region_entry could be either pci_device.bar or pci_bridge.region. >> Both approaches will work fine in the end. I don't care much, I just >> want something that works. It's probably a bit risky to merge Alexey's >> version before the planned mid-march release. > FYI - the plan is to feature freeze in mid-march. A question about lists, shall I move lists operation to header file and make use the list service functions for PMM and Stack code or it will be applied later as a code "optimization"?