Thread (13 messages) 13 messages, 3 authors, 2012-05-31

Re: [PATCH 0/3] Generic rb tree code

From: Tejun Heo <hidden>
Date: 2012-05-29 05:28:54
Also in: lkml

Hello, Kent.

On Mon, May 28, 2012 at 11:30:32PM -0400, Kent Overstreet wrote:
quoted
Modeled after spinlock code how?  AFAICS, spinlock code doesn't
present inline and !inline versions to users. 
That probably wasn't intended, but it's how it works out.
__raw_spin_lock() and all the variants are defined as inline functions,
and then depending on whether CONFIG_INLINE_BLAH is enabled
_raw_spin_lock_blah() is defined to __raw_spin_lock_blah(), otherwise
_raw_spin_lock_blah() is a wrapper in a .c file.

But the end result is that the inline versions are also available.
Doesn't matter.  Nobody outside spinlock implementation proper should
be using them.
quoted
All the current users
are inline anyway, why not just provide inlined versions and worry
about whether inlining is beneifical in a separate patch?
Yeah, possible. I think it's only going to be an issue for rb_search()
in practice (since rb_search needs the stack allocated search argument),
should probably just drop the inline version of rb_insert().
As long as there's single version of the thing....

Thanks.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help