Skip to contentSkip to conversation

x86: export pv_lock_ops non-GPL

PATCH In review Jeremy Fitzhardinge 2 participants 4 messages Aug 20, 2008 – Aug 21, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 x86: export pv_lock_ops non-GPL

None of the spinlock API is exported GPL, so there's no reason for pv_lock_ops to be.

---
 arch/x86/kernel/paravirt-spinlocks.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

===================================================================

arch/x86/kernel/paravirt-spinlocks.c +1 -1
@@ -17,7 +17,7 @@
 	.spin_unlock = __ticket_spin_unlock,
 #endif
 };
-EXPORT_SYMBOL_GPL(pv_lock_ops);
+EXPORT_SYMBOL(pv_lock_ops);
 
 void __init paravirt_use_bytelocks(void)
 {
#1 lore raw
Quoted 2 lines · Jeremy Fitzhardinge

None of the spinlock API is exported GPL, so there's no reason for pv_lock_ops to be.

uhm, why is this even a question? All of this stuff is so deep inside the guts of the kernel ... so nope - if then we want to change the others to _GPL exports as well, just to make sure nobody gets funny ideas.

Ingo

#2 lore raw
Quoted 9 lines · Ingo Molnar
Quoted 2 lines · Jeremy Fitzhardinge

None of the spinlock API is exported GPL, so there's no reason for pv_lock_ops to be.

uhm, why is this even a question? All of this stuff is so deep inside the guts of the kernel ... so nope - if then we want to change the others to _GPL exports as well, just to make sure nobody gets funny ideas.

i've nevertheless applied it to tip/x86/urgent - but it would be nice to clean all of this up and only export the minimally necessary (ex include file inline functions) APIs and none of the paravirt stuff.

Ingo

#3 lore raw
In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar

uhm, why is this even a question? All of this stuff is so deep inside the guts of the kernel ... so nope - if then we want to change the others to _GPL exports as well, just to make sure nobody gets funny ideas.

pv_lock_ops gets accessed by inline functions which get inlined into modules. They should never directly access it, but the generated code will. _spin_lock() is in exactly the same situation.

J