[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1102162143430.2701@localhost6.localdomain6>
Date: Wed, 16 Feb 2011 21:45:30 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
cc: David Daney <ddaney@...iumnetworks.com>,
Roland McGrath <roland@...hat.com>,
Mark Wielaard <mjw@...hat.com>,
Stefan Hajnoczi <stefanha@...il.com>,
"Frank Ch. Eigler" <fche@...hat.com>,
Julien Desfossez <julien.desfossez@...ymtl.ca>,
dominique.toupin@...csson.com, ltt-dev@...ts.casi.polymtl.ca,
systemtap@...rces.redhat.com, linux-kernel@...r.kernel.org,
Jason Baron <jbaron@...hat.com>, hpa@...or.com,
rostedt@...dmis.org, mingo@...e.hu, andi@...stfloor.org,
rth@...hat.com, masami.hiramatsu.pt@...achi.com,
fweisbec@...il.com, avi@...hat.com, davem@...emloft.net,
sam@...nborg.org, michael@...erman.id.au,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: Porting "jump labels" to userspace
On Wed, 16 Feb 2011, Mathieu Desnoyers wrote:
> * David Daney (ddaney@...iumnetworks.com) wrote:
> > On 02/16/2011 12:04 PM, Roland McGrath wrote:
> >> IMHO there is not really so much to the in-kernel implementation that it's
> >> worth attempting to reuse the code in userland. Pretty much all the work
> >> is in the details of the implementation that would naturally differ a lot
> >> in a different context. If you understand the mechanism and the machine
> >> details, then implementing it well for a userland context is not a big deal
> >> and is cleaner to do from scratch than shoe-horning kernel-centric code
> >> into a wildly different context.
> >>
> >
> > Good point.
> >
> > Certainly the details of maintaining instruction cache coherency may be
> > different in userspace.
>
> Indeed, the arch-specific parts will need some extra care (which might, in the
> worse case scenario, require to suspend a whole process during the update), but
> the generic code in jump_label.c and jump_label.h could certainly be reused.
We talk about 500 lines of code, where half of it is modules specific
and the whole thing is full of kernelims. IMNSHO, that's faster
reimplemented from scratch than writing all the mails and get the
authors to sign off on the license change.
Thanks,
tglx
--
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