lkml.org 
[lkml]   [2004]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] kref shrinkage patches -- 1 of 2 -- kref shrinkage
On Wed, Jul 21, 2004 at 02:14:18AM -0400, Greg KH wrote:
> ...
> > Just had a question about definition of kref_get though,
> > why does it need to return struct kref * ? struct kref * is anywayz
> > being passed to it, hence the caller has it anywayz -- so it doesn't
> > value add anything afaics (but i might have limited vision so pls correct me)
>
> Consistancy with other "get" and "put" functions. It's quite common to
> do:
> have_this_foo(foo_get(foo));
>
> or:
> foo_to_send_off = foo_get(foo);
>

kref_get is invoked from inside foo_get in such cases no? so foo_get
can do kref_get and return struct *foo...like in usb_serial_get_by_index?

Even assuming foo_get is altogether replaced with kref_get, which might
not be a very common case (looking at the current usage, and future usage in
fget_light etc)
we will still have to do
foo_to_send_off = KREF_TO_FOO(kref_get(&foo->kref));
instead :
kref_get(&foo->kref);
foo_to_send_off = foo;
is better right? Why use a macro for just one extra line of code....
Looking at the current usage and looking at refcount 'getters'
like fget, mntget etc., 'doesn't look like people will use the return
value from kref_get much anywayz. Since the api is young is it better to
kill the return value now than let people misuse the return type like in the
scsi subsystem?
Thanks,
Kiran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [from the cache]
©2003-2011 Jasper Spaans