* kernel_thread() for non-GPL drivers
@ 2015-06-02 19:43 Ani Sinha
2015-06-02 20:31 ` Al Viro
0 siblings, 1 reply; 2+ messages in thread
From: Ani Sinha @ 2015-06-02 19:43 UTC (permalink / raw)
To: Al Viro, linux-kernel@vger.kernel.org, fruggeri, Ivan Delalande
Hi Al :
I see that there has been some code re-org in linux 3.7 starting with
commit 7076aada1040de4ed79a5977dbabdb5e5ea5e249
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Sep 10 16:44:54 2012 -0400
x86: split ret_from_fork
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This removed the kernel_thread() x86 specific function that was
exported to all drivers. Then the following commit added a generic
kernel_thread() function which no longer can be used by modules
because the symbol is not exported anymore :
commit 2aa3a7f8660355c3dddead17e224545c1a3d5a5f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri Sep 21 19:55:31 2012 -0400
preparation for generic kernel_thread()
Let architectures select GENERIC_KERNEL_THREAD and have their copy_thread()
treat NULL regs as "it came from kernel_thread(), sp argument contains
the function new thread will be calling and stack_size - the argument for
that function". Switching the architectures begins shortly...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
All arch specific code now uses this as all of them has
GENERIC_KERNEL_THREAD turned on and then later eventually this #ifdef
was also removed:
commit ae903caae267154de7cf8576b130ff474630596b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri Dec 14 12:44:11 2012 -0500
Bury the conditionals from kernel_thread/kernel_execve series
All architectures have
CONFIG_GENERIC_KERNEL_THREAD
CONFIG_GENERIC_KERNEL_EXECVE
__ARCH_WANT_SYS_EXECVE
None of them have __ARCH_WANT_KERNEL_EXECVE and there are only two callers
of kernel_execve() (which is a trivial wrapper for do_execve() now) left.
Kill the conditionals and make both callers use do_execve().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
So my question to you is, which api (for x86) are drivers supposed to
use if kernel_thread() is no longer available? It looks to me like
maybe we can use kthread_run() which eventually lazily creates a
kernel thread. Is my understanding correct?
Cheers,
ani
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: kernel_thread() for non-GPL drivers
2015-06-02 19:43 kernel_thread() for non-GPL drivers Ani Sinha
@ 2015-06-02 20:31 ` Al Viro
0 siblings, 0 replies; 2+ messages in thread
From: Al Viro @ 2015-06-02 20:31 UTC (permalink / raw)
To: Ani Sinha; +Cc: linux-kernel@vger.kernel.org, fruggeri, Ivan Delalande
On Tue, Jun 02, 2015 at 12:43:15PM -0700, Ani Sinha wrote:
> So my question to you is, which api (for x86) are drivers supposed to
> use if kernel_thread() is no longer available? It looks to me like
> maybe we can use kthread_run() which eventually lazily creates a
> kernel thread. Is my understanding correct?
First of all, what the hell does it have to do with GPL? Or modules
vs. built-in, for that matter... kernel_thread() is _not_ what it
used to be way back and export or no export, your driver isn't going
to be happy with it.
kthread_run() had been there for more than 11 years, for crying out loud!
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-06-02 20:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-02 19:43 kernel_thread() for non-GPL drivers Ani Sinha
2015-06-02 20:31 ` Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox