From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: jeremy@goop.org, fujita.tomonori@lab.ntt.co.jp,
hpa@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: Modularizing IOMMUs (devel/iommu-0.4)
Date: Fri, 22 Oct 2010 09:54:39 -0400 [thread overview]
Message-ID: <20101022135439.GA23030@dumpdata.com> (raw)
In-Reply-To: <4CC15EE9020000780001E8B5@vpn.id2.novell.com>
On Fri, Oct 22, 2010 at 08:52:41AM +0100, Jan Beulich wrote:
> >>> On 20.10.10 at 22:20, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > Another way, less elegant was to manually enforce each function to be stuck
> > in the .iommu_text section. For that I made a macro: __iommu that would
> > force the function to be stuck in section specific for the IOMMU. So all
> > functions in pci-gart_64.c would be funneled in .iommu.gart.text. For
> > calgary:
> > .iommu.calgary.text., and so on. This is accomplished by having at the
> > beginning
> > of the the file the name of the IOMMU section, as so:
> >
> > #define IOMMU_MODULE "gart"
> >
> > And all of the functions would get stuck in .iommu.gart.text.
>
> For this particular approach - did you consider using objcopy's
> --rename-section option?
<goes off to look at that>
>
> > And then Question #3): Is there a better way?
>
> Generally I like hpa's suggestion of using pre-loaded but unloadable
> modules much better, not the least because in the past I had seen
> potential uses for such a mechanism in other places of the kernel.
<nods> It does sound like the right option. 12 years ago it was suggested,
so.. how come nobody worked on it in the past? Were there some epic battles?
next prev parent reply other threads:[~2010-10-22 13:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 20:20 Modularizing IOMMUs (devel/iommu-0.4) Konrad Rzeszutek Wilk
2010-10-20 20:23 ` H. Peter Anvin
2010-10-22 7:52 ` Jan Beulich
2010-10-22 13:54 ` Konrad Rzeszutek Wilk [this message]
2010-10-22 17:13 ` H. Peter Anvin
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=20101022135439.GA23030@dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@novell.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hpa@linux.intel.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox