From: Alexey Korolev <alexey.korolev@endace.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: mst@redhat.com, sfd@endace.com, seabios@seabios.org,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
avi@redhat.com
Subject: Re: [Qemu-devel] [SeaBIOS] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2)
Date: Tue, 6 Mar 2012 17:44:20 +1300 [thread overview]
Message-ID: <4F559624.6000904@endace.com> (raw)
In-Reply-To: <20120305134910.GB9697@morn.localdomain>
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"?
prev parent reply other threads:[~2012-03-06 4:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 5:50 [Qemu-devel] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2) Alexey Korolev
2012-03-01 6:05 ` [Qemu-devel] [Seabios] [PATCH 1/6] Adding new structures Alexey Korolev
2012-03-01 6:15 ` [Qemu-devel] [PATCH 2/6] New service functions and ported old functions to 64bit Alexey Korolev
2012-03-01 6:40 ` [Qemu-devel] [PATCH 3/6] Fill PCI regions with etnries Alexey Korolev
2012-03-01 6:57 ` [Qemu-devel] [PATCH 4/6] Mapping of BARs and Bridge regions Alexey Korolev
2012-03-01 9:22 ` [Qemu-devel] [SeaBIOS] " Gerd Hoffmann
2012-03-01 22:01 ` Alexey Korolev
2012-03-02 7:21 ` Gerd Hoffmann
2012-03-05 5:31 ` Alexey Korolev
2012-03-01 7:02 ` [Qemu-devel] [PATCH 5/6] Delete old code Alexey Korolev
2012-03-01 7:11 ` [Qemu-devel] [PATCH 6/6] 64bit PCI range in _CRS table Alexey Korolev
2012-03-01 9:05 ` [Qemu-devel] [SeaBIOS] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2) Gerd Hoffmann
2012-03-01 21:48 ` Alexey Korolev
2012-03-02 7:08 ` Gerd Hoffmann
2012-03-05 5:34 ` Alexey Korolev
2012-03-05 10:12 ` Gerd Hoffmann
2012-03-06 4:28 ` Alexey Korolev
2012-03-04 19:40 ` [Qemu-devel] " Kevin O'Connor
2012-03-05 6:03 ` Alexey Korolev
2012-03-05 13:16 ` Kevin O'Connor
2012-03-05 9:53 ` [Qemu-devel] [SeaBIOS] " Gerd Hoffmann
2012-03-05 13:49 ` Kevin O'Connor
2012-03-06 4:44 ` Alexey Korolev [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F559624.6000904@endace.com \
--to=alexey.korolev@endace.com \
--cc=avi@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=sfd@endace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.