* Ingo Molnar (mingo@xxxxxxx) wrote:
>
> * Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
>
> > > it's offline right now:
> > >
> > > $ git clone git://git.lttng.org/urcu
> > > Cloning into urcu...
> > > fatal: The remote end hung up unexpectedly
> >
> > This would be:
> >
> > git clone git://git.lttng.org/userspace-rcu.git
>
> Hey, my impression wasn't *entirely* wrong, your initial urcu commit:
>
> From 27b012e271a82b9a0d94543688904f207cd154ea Mon Sep 17 00:00:00 2001
> From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
> Date: Thu, 5 Feb 2009 19:06:44 -0500
> Subject: [PATCH] init version
>
> ---
> Makefile | 6 ++
> urcu.c | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> urcu.h | 69 +++++++++++++++++
> 3 files changed, 325 insertions(+), 0 deletions(-)
>
> Has:
>
> +/* The "volatile" is due to gcc bugs */
> +#define barrier() __asm__ __volatile__("": : :"memory")
> +
>
> Which code sequence i recognize very well as a kernel maintainer ;-)
> Here's the kernel's compiler.h definition of the same:
>
> /* The "volatile" is due to gcc bugs */
> #define barrier() __asm__ __volatile__("": : :"memory")
>
> This:
>
> +/* x86 32/64 specific */
> +#define mb() asm volatile("mfence":::"memory")
> +#define rmb() asm volatile("lfence":::"memory")
> +#define wmb() asm volatile("sfence" ::: "memory")
> +
> +
> +
> +/* x86 32 */
> +static inline void atomic_inc(int *v)
> +{
> + asm volatile("lock; incl %0"
> + : "+m" (v->counter));
>
> is familiar to an arch/x86/ maintainer as well :-)
>
> So yes, kernel code was obviously used in the making of urcu - just
> not the RCU kernel code it appears.
>
> Which is a pity i think! :-)
Heh :) You know, I really like the Linux kernel coding style, which is
what I tried to stick to within this library. So although I initially
imported some of the core Linux kernel macroisms, I had to reimplement
them (derived from a MIT-licensed code-base) as soon as I decided to go
for MIT-licensed low-level primitives and LGPL-licensed library.
About RCU, the picture seemed very much different in the userspace
landscape compared to the kernel (needed to use of per-thread RCU
nesting counters compared to per-CPU in the kernel because of lack of
integration with the scheduler), but more on that in my other follow-up
reply.
Thanks,
Mathieu
>
> Thanks,
>
> Ingo
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
