[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081203185627.64fdb0fc@extreme>
Date: Wed, 3 Dec 2008 18:56:27 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Randy Dunlap <randy.dunlap@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King <rmk+lkml@....linux.org.uk>,
linux-kernel@...r.kernel.org,
Stephen Rothwell <sfr@...b.auug.org.au>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Yet more ARM breakage in linux-next
On Thu, 4 Dec 2008 11:57:14 +1030
Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Thursday 04 December 2008 10:07:44 Randy Dunlap wrote:
> > Rusty Russell wrote:
> > > (Yes, classic useless kerneldoc documentation doesn't actually *say*
> > > this clearly).
> >
> > oh fud. That's not a fault of kernel-doc, just of whoever wrote it.
> > It's only as good as someone makes it.
>
> Sorry that this came out wrong. kernel-doc provides structure, but it can't
> provide content. And authors seem unable to think from the POV of someone
> *using* the API.
>
> With some work, I tracked it back to Stephen Hemminger for this comment in
> 12d9c8420b9daa1da3d9e090640fb24bcd0deba2. It's since been fixed and moved,
> but it's still:
>
> * __fls: find last set bit in word
> * @word: The word to search
> *
> * Undefined if no set bit exists, so code should check against 0 first.
>
> Which would be *fine* if fls() didn't have such confusing bit numbering and
> the exact same one-line description.
>
> Thanks,
> Rusty.
I think the idea was that fls was supposed to match ffs which had stupid
bit numbering inherited from BSD. and __ffs and __fls were same
but undefined if word is 0 so that they could just be one line asm.
--
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