Re: [RFC] ->get_link(), ->put_link() and cookies

[Al Viro]

On Sun, Jan 03, 2016 at 12:41:47PM -0800, Linus Torvalds wrote:

> I like how it removes "put_link()" as a callback, but at the same time
> I think it's even more abstract than the cookie was.
> 
> The main worry I have is that the naming is generic, but there's only
> a single very specialized use for it. Do we expect other uses?

Quite possibly - I don't have anything specific planned right now, but
I would be surprised if there hadn't been open-coded equivalents
of that thing in many places, and not only "too many instances to touch"
kind of holy cows, at that (timers are obviously very similar, but these
_do_ have way too many instances to even think of converting them).

> Because if not, I think it would be clearer if it was named to be more
> concretely about putlink, and avoid the fact that it feels very
> abstract.
> 
> Don't get me wrong - abstract generalized helper functions are cool.
> But people aren't very abstract, and it tends to make for confusing
> code when you aren't intimately familiar with the rules.

The rules are pretty simple - there are 4 primitives total.
1) DEFINE_DELAYED_CALL(name) - usual DEFINE_MUTEX, etc. style initialized
declaration.
2) set_delayed_call(delayed_call, function, argument) - function is
void(void *), argument is void *.  A-la setup_timer().
3) clear_delayed_call(delayed_call) - resets.
4) do_delayed_call(delayed_call) - evaluates.

That's it.  If you have better suggestions re names, I'd be glad to take
them, but the set of primitives and the rules to go with those are as
simple as it gets.

Sure, we can give it a less generic name for now and just do what we'd done
for another generic thing (rcu_head, aka callback_head) when unrelated
uses show up, but I don't see much point going that way, TBH...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/