Re: workqueue: inline trivial wrappers

[Tejun Heo]

Hello,

On Mon, May 06, 2013 at 10:44:58AM -0400, Marc Dionne wrote:
> On Mon, Apr 29, 2013 at 10:31 PM, Linux Kernel Mailing List
> <linux-kernel@xxxxxxxxxxxxxxx> wrote:
> > Gitweb:     http://git.kernel.org/linus/;a=commit;h=8425e3d5bdbe8e741d2c73cf3189ed59b4038b84
> > Commit:     8425e3d5bdbe8e741d2c73cf3189ed59b4038b84
> > Parent:     611c92a0203091bb022edec7e2d8b765fe148622
> > Author:     Tejun Heo <tj@xxxxxxxxxx>
> > AuthorDate: Wed Mar 13 16:51:36 2013 -0700
> > Committer:  Tejun Heo <tj@xxxxxxxxxx>
> > CommitDate: Wed Mar 13 16:51:36 2013 -0700
> >
> >     workqueue: inline trivial wrappers
> >
> >     There's no reason to make these trivial wrappers full (exported)
> >     functions.  Inline the followings.
> >
> >      queue_work()
> >      queue_delayed_work()
> >      mod_delayed_work()
> >      schedule_work_on()
> >      schedule_work()
> >      schedule_delayed_work_on()
> >      schedule_delayed_work()
> >      keventd_up()
> >
> >     Signed-off-by: Tejun Heo <tj@xxxxxxxxxx>
> 
> This commit has the side effect of making some functions
> EXPORT_SYMBOL_GPL that had been previously exported with EXPORT_SYMBOL
> for a long time, such as schedule_work().  This is used by OpenAFS and
> probably other out of tree modules.  Past exchanges on this list (ex:
> http://marc.info/?l=linux-fsdevel&m=123550631318910) suggest the
> license requirements for existing interfaces shouldn't change, at
> least without providing an alternate means of getting the same
> functionality.  Any thoughts on whether this can be adjusted within
> the current release cycle?

Hah, so schedule_work() was EXPORT_SYMBOL() and queue_work*() were
EXPORT_SYMBOL_GPL()?  It'd be rather silly to avoid inlining those
wrappers for license reasons.  Can you please send a patch changing
the necessary functions to EXPORT_SYMBOL()?

Thanks.

-- 
tejun
--
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/