LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH 05/10] local_t : mips extension
Date: Fri, 26 Jan 2007 11:57:12 -0500	[thread overview]
Message-ID: <20070126165712.GA21098@Krystal> (raw)
In-Reply-To: <20070126163623.GB26138@Krystal>

* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > What I generally dislike about this patch is that several fairly large
> > functions have been duplicated with only little change.
> > 
> 
> Yeah, I know. Until we find some way to share atomic operation code for
> both operation on local and shared data, we have to duplicate this. We
> could think about a header that would support multiple inclusion and
> behave differently (different function prefix and LOCKing/memory
> barriers) depending on defines set by the top level header.
> 
> Something like
> 
> asm/atomic.h
>   #define ATOMIC_SHARED
>   #include <asm/atomic-ops.h>  /* shared */
>   #undef ATOMIC_SHARED
>   #include <asm/atomic-ops.h>  /* local */
> 
> asm/atomic-ops.h 
>   #ifdef ATOMIC_SHARED
>   #define ATOMIC_PREFIX atomic
>   #define ATOMIC_BARRIER() smp_mb()
>   #define ATOMIC_TYPE atomic_t
>   #define ATOMIC_VAR (v->counter)
>   #else
>   #define ATOMIC_PREFIX local
>   #define ATOMIC_BARRIER()
>   #define ATOMIC_TYPE local_t
>   #define ATOMIC_VAR (v->a.counter)
>   #endif
>   
>   static __inline__ ATOMIC_PREFIX##_add_return(int i, ATOMIC_TYPE *v)
>   .....
>   #undef ATOMIC_PREFIX
>   #undef ATOMIC_BARRIER
>   #undef ATOMIC_TYPE
>   #undef ATOMIC_VAR
> 

More prefisely, for this to work, we should change :
#define ATOMIC_PREFIX atomic
and
#define ATOMIC_PREFIX local
for

#define ATOMICF(fctname) atomic_##fctname
and
#define ATOMICF(fctname) local_##fctname


which would make de declaration look like :

static __inline__ ATOMICF(add_return)(int i, ATOMIC_TYPE *v)

Which starts to look a little odd to me, doesn't it ?

Regards,

Mathieu

-- 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

  reply	other threads:[~2007-01-26 16:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 16:16 [PATCH 00/10] local_t : adding and standardising local atomic primitives Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 01/10] local_t : architecture independant extension Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 02/10] local_t : alpha extension Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 03/10] local_t : i386 extension Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 04/10] local_t : ia64 extension Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 05/10] local_t : mips extension Mathieu Desnoyers
2007-01-26 12:04   ` Ralf Baechle
2007-01-26 16:36     ` Mathieu Desnoyers
2007-01-26 16:57       ` Mathieu Desnoyers [this message]
2007-01-25 16:16 ` [PATCH 06/10] local_t : parisc cleanup Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 07/10] local_t : powerpc extension Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 08/10] local_t : s390 cleanup Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 09/10] local_t : sparc64 cleanup Mathieu Desnoyers
2007-01-25 16:16 ` [PATCH 10/10] local_t : x86_64 extension Mathieu Desnoyers
  -- strict thread matches above, loose matches on Subject: below --
2007-02-11 19:18 [PATCH 00/10] local_t : adding and standardising local atomic primitives Mathieu Desnoyers
2007-02-11 19:18 ` [PATCH 05/10] local_t : mips extension Mathieu Desnoyers
2007-01-12  1:42 [PATCH 00/10] local_t : adding and standardising local atomic primitives Mathieu Desnoyers
2007-01-12  1:42 ` [PATCH 05/10] local_t : mips extension Mathieu Desnoyers

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=20070126165712.GA21098@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --subject='Re: [PATCH 05/10] local_t : mips extension' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).