[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130906143909.GC5140@phenom.dumpdata.com>
Date: Fri, 6 Sep 2013 10:39:09 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Jan Beulich <JBeulich@...e.com>
Cc: david.vrabel@...rix.com,
xen-devel <xen-devel@...ts.xenproject.org>,
boris.ostrovsky@...cle.com, linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen/p2m: Export set_phys_to_machine.
On Fri, Sep 06, 2013 at 03:06:02PM +0100, Jan Beulich wrote:
> >>> On 06.09.13 at 16:00, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> > We have already exported 'get_phys_to_machine' and there are
> > third-party drivers that depend on this other symbol. As such
> > lets make this balanced and also export this symbol.
>
> I tend to disagree: Allowing external modules read access to some
> internal state is quite different from also allowing them to alter it.
I am not following you. We have drivers in the kernel that do
this now. For example xen-netfront uses set_phys_to_machine.
Oddly it can be built as a module. I am wondering how it actually
works without this EXPORT symbol.
>
> Jan
>
> > Reported-by: Yuval Shaia <yuval.shaia@...cle.com>
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > ---
> > arch/x86/xen/p2m.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> > index 0d4ec35..cdb96bc 100644
> > --- a/arch/x86/xen/p2m.c
> > +++ b/arch/x86/xen/p2m.c
> > @@ -847,6 +847,7 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
> >
> > return true;
> > }
> > +EXPORT_SYMBOL_GPL(set_phys_to_machine);
> >
> > #define M2P_OVERRIDE_HASH_SHIFT 10
> > #define M2P_OVERRIDE_HASH (1 << M2P_OVERRIDE_HASH_SHIFT)
> > --
> > 1.8.3.1
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@...ts.xen.org
> > http://lists.xen.org/xen-devel
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists