All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: James Bottomley <James.Bottomley@steeleye.com>
Cc: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Intel Alder IOAPIC fix
Date: 15 Jan 2004 22:32:23 -0700	[thread overview]
Message-ID: <m13cagbgrc.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1074196460.1868.250.camel@mulgrave>

James Bottomley <James.Bottomley@steeleye.com> writes:

> On Thu, 2004-01-15 at 14:26, Eric W. Biederman wrote:
> > And end up looking like:
> > fec00000-fec00fff : reserved
> > fec01000-fec013ff : 0000:00:0f.0
> > fec01400-fec08fff : reserved
> 
> Oh, I see you're splitting an existing resource around it.

Yes, this is the extreme case.  In normal cases I would just
expect to push to one side and probably shrink it to 0.  I guess
I have something against implying a hierarchal relationship that
does not exist.
 
> So the e820 map requests reserved regions with tentative and
> insert_resource is allowed to place resources into tentative regions. 
> That works for me, but I don't see how it works for the bridge
> case...there you really want to insert the bridge resource over
> everything else.

Right.  To me it looks like separate cases.  What I keep envisioning
scanning the PCI devices and then realizing they are behind
a bridge.  Before I go to far I guess I should ask.

The splitting/pushing aside looks especially useful for those
cases where you subdivide the resource again.

As for the bridge case I think that is something different.  

Eric

  reply	other threads:[~2004-01-16  5:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-12  2:55 [PATCH] Intel Alder IOAPIC fix James Bottomley
2004-01-12 21:24 ` Linus Torvalds
2004-01-12 22:13   ` James Bottomley
2004-01-12 23:04   ` James Bottomley
2004-01-12 23:04     ` Linus Torvalds
2004-01-13  0:25       ` James Bottomley
2004-01-13  0:45       ` James Bottomley
2004-01-13  0:25         ` Linus Torvalds
2004-01-13 16:52           ` James Bottomley
2004-01-15  5:18             ` Eric W. Biederman
2004-01-15 16:58               ` James Bottomley
2004-01-15 19:26                 ` Eric W. Biederman
2004-01-15 19:54                   ` James Bottomley
2004-01-16  5:32                     ` Eric W. Biederman [this message]
2004-01-17 15:18                       ` James Bottomley
2004-01-17 19:43                         ` Eric W. Biederman

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=m13cagbgrc.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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.