Re: [PATCH 1/9] kernel: export sound/core/pcm_timer.c gcd implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2 Jun 2009 09:19:22 +0200 Florian Fainelli <florian@xxxxxxxxxxx> wrote:

> Le Tuesday 02 June 2009 06:50:34 Andrew Morton, vous avez __crit__:
> > On Mon, 1 Jun 2009 13:57:09 +0200 Florian Fainelli <florian@xxxxxxxxxxx> 
> wrote:
> > > This patch exports the gcd implementation from
> > > sound/core/pcm_timer.c into include/linux/kernel.h.
> > > AR7 uses it in its clock routines.
> > >
> > > ...
> > >
> > > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > > index 883cd44..878a27a 100644
> > > --- a/include/linux/kernel.h
> > > +++ b/include/linux/kernel.h
> > > @@ -147,6 +147,22 @@ extern int _cond_resched(void);
> > >  		(__x < 0) ? -__x : __x;		\
> > >  	})
> > >
> > > +/* Greatest common divisor */
> > > +static inline unsigned long gcd(unsigned long a, unsigned long b)
> > > +{
> > > +        unsigned long r;
> > > +        if (a < b) {
> > > +                r = a;
> > > +                a = b;
> > > +                b = r;
> > > +        }
> > > +        while ((r = a % b) != 0) {
> > > +                a = b;
> > > +                b = r;
> > > +        }
> > > +        return b;
> > > +}
> >
> > a) the name's a bit sucky.   Is there some convention for this name?
> 
> We might want something better like greatest_common_divisor which is a bit 
> more self-explanatory ?

Well, if gcd() is a commonly used name then let's use that.  I don't
personally recall seeing it used but that doesn't mean much.

> >
> > b) It looks too large to be inlined.  lib/gdc.c?
> 
> And its users select it in order not to increase the size of kernel.h, sounds 
> good.
> 
> >
> > b) there's an implementation of gcd() in
> >    net/netfilter/ipvs/ip_vs_wrr.c.  I expect that this patch broke the
> >    build.
> 
> I did forget about this. That gcd implementation only treats the a > b case.
> 
> What do you prefer, each user keeps its gcd implementation locally or we make 
> a lib/gcd.c for it ?

I think lib/gcd.c would be better.  Then migrate current code over to
use that.

The problem with offering a generic version is types: will it work
correctly and sensibly for all combinations of signed/unsigned
char/short/int/long/longlong?  All but the last, I expect.  In which
case that'll be good enough for now.


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux