qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: Alexey Korolev <alexey.korolev@endace.com>
Cc: mst@redhat.com, sfd@endace.com, seabios@seabios.org,
	qemu-devel@nongnu.org, avi@redhat.com,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [Seabios] [PATCH 0/6] 64bit PCI BARs allocations (take 2)
Date: Mon, 5 Mar 2012 08:16:38 -0500	[thread overview]
Message-ID: <20120305131637.GA9697@morn.localdomain> (raw)
In-Reply-To: <4F54571C.8040503@endace.com>

On Mon, Mar 05, 2012 at 07:03:08PM +1300, Alexey Korolev wrote:
> > On Thu, Mar 01, 2012 at 06:50:43PM +1300, Alexey Korolev wrote:
> >> In the 6th patch we clear old code.
> > 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.

> I understand your point, will rework.
> Would it be reasonable if I send one patch series for redesign of existing implementation
> and another one for 64bit support?

Sending two patch series would be preferable.  One series that
converts the existing functionality to your new data structures, and
one series that adds new capabilities.

> > Also, since Gerd has some patches pending in this area, we should
> > figure out which direction makes sense.  Can you explain on how this
> > 64bit support is different from the support proposed by Gerd?
> 
> Ah it's a difficult thing, I don't want to criticise. You'll hate me :).
> 
> I think Gerd's implementation is about saving existing approach and having 64bit BARs support
> with incremental sort of changes. It is reasonable, but causes the code to be bulky, and adding extra types
> (PCI_REGION_TYPE_PREFMEM64) is a bit misleading.

I agree that PCI_REGION_TYPE_PREFMEM64 doesn't make sense to me.

> 3. About RAM use (may not be important), but lets count:

FYI - ram use doesn't really matter.  In any reasonable config there
will be multiple megabytes of ram available.  The ram allocated with
malloc_tmp is not reserved beyond the BIOS init phase.

-Kevin

  reply	other threads:[~2012-03-05 13:17 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 [this message]
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

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=20120305131637.GA9697@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=alexey.korolev@endace.com \
    --cc=avi@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).