On Thu, Jan 17, 2013 at 7:04 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> Another thing is that it seems like having introspection type
> interface often lead to abuses - work_pending(), work_busy() both
> ended up bringing more unnecessary dependencies and subtle bugginess
> on internal details than actual benefits. Querying %current is much
> less likely to be harmful in itself but I'm afraid it might encourage
> its users to develop something crazy on top. It might be a good idea
> to make it only available to async.
I'm not sure I understand what you mean? Do you mean trying to limit
work_current_func() to only be accessible to the async code? You'd
have to make some kind of private header file under kernel/ for that,
but I guess that would work fine. We already do something similar
inside filesystems etc, where they have their own local headers.
I still don't really see what other data the async code could possibly
ever want than the "is this an async thread" I guess if you want to
keep all these things private to their own C files with no leaving of
the structure definitions (even within just a private kernel/worker.h
file or something) you could make the interface be one like
- kernel/workqueue.c:
int current_uses_workfn(work_func_t match)
{
if (current->flags & PF_WQ_WORKER) {
struct worker *worker = kthread_data(current);
return worker && match == worker->current_func;
}
return 0;
}
- kernel/async.c:
int current_is_async(void)
{
return current_uses_workfn(async_run_entry_fn);
}
but quite frankly, we've generally tried to avoid those kinds of silly
wrappers just because it's very wasteful to do two function calls just
to hide some detail like this. The code generation is atrocious,
jumping around for no good reason just increases cache pressure etc.
Yes, yes, some globally optimizing compiler could sort it all out, but
I'd personally be inclined to just move all the structure definitions
into kernel/worker.h, and make the code be inline functions. The only
actual current *user* would also be in the kernel/ subdirectory, and
we don't know if we'd ever want to really expand it past there.
Hmm?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
