[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200708090224.16328.ak@suse.de>
Date: Thu, 9 Aug 2007 02:24:16 +0200
From: Andi Kleen <ak@...e.de>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Glauber de Oliveira Costa <glommer@...il.com>,
Glauber de Oliveira Costa <gcosta@...hat.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
mingo@...e.hu, chrisw@...s-sol.org, jeremy@...p.org,
avi@...ranet.com, anthony@...emonkey.ws,
virtualization@...ts.linux-foundation.org, lguest@...abs.org,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 25/25] [PATCH] add paravirtualization support for x86_64
On Thursday 09 August 2007 01:18:57 Rusty Russell wrote:
> On Wed, 2007-08-08 at 11:49 -0300, Glauber de Oliveira Costa wrote:
> > On 8/8/07, Andi Kleen <ak@...e.de> wrote:
> > > > +EXPORT_SYMBOL(paravirt_ops);
> > >
> > > Definitely _GPL at least.
> > Sure.
>
> We ended up making it EXPORT_SYMBOL in i386 because every driver wants
> to save and restore interrupt state.
Ah true.
> But questionably-licensed drivers might be less of a concern on x86-64.
Nvidia/ATI and other binary modules exist too and users will probably unhappy
if they cannot run them anymore.
But at usually irq state changes should be patched in anyways and won't
need paravirt I guess?
Hmm, actually thinking about it the module loader probably has no clue
that the relocation it linked will be overwritten so it'll check
for the export anyways.
So the alternatives would be to add ugly hacks to the module loader
or split paravirt_ops in "common" and "low level system" areas or
export it as a normal export.
Not sure what's best. Ok using a normal export is easiest and not
that big an issue.
-Andi
-
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