[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100430180520.GB9043@redhat.com>
Date: Fri, 30 Apr 2010 20:05:20 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: Arve Hjønnevåg <arve@...roid.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Alan Stern <stern@...land.harvard.edu>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 2/2] workqueues: export keventd_wq
On 04/30, Tejun Heo wrote:
>
> On 04/30/2010 07:39 AM, Arve Hjønnevåg wrote:
> > On Thu, Apr 29, 2010 at 10:16 PM, Tejun Heo <tj@...nel.org> wrote:
> >> Hello,
> >>
> >> On 04/29/2010 09:45 PM, Oleg Nesterov wrote:
> >>> -static struct workqueue_struct *keventd_wq __read_mostly;
> >>> +struct workqueue_struct *keventd_wq __read_mostly;
> >>> +EXPORT_SYMBOL(keventd_wq);
> >>
> >> Umm... does it have to be EXPORTed? Suspend block API can't be built
> >> as a module, right?
Right, but this allows to make schedule_xxx/flush_scheduled_work
inline and kill more EXPORT_SYMBOL's, and cmwq exports it anyway
(iirc it also renames it).
> > The suspend block api cannot be built as a module, but if
> > schedule_suspend_blocking_work will just call
> > queue_suspend_blocking_work(keventd_wq, work) it may as well be an
> > inline function which would require the export.
>
> I think it would be better to keep the thing inside the kernel, at
> least for now.
But then schedule_suspend_blocking_work() in turn needs EXPORT_SYMBOL().
OK. Let's forget this patch. We can unify schedule_suspend_blocking_work
and queue_suspend_blocking_work later, or Arve can add this export into
his patch (without EXPORT_SYMBOL) - either way I agree. This is very
minor issue, I regret I originated this almost offtopic noise ;)
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists