Skip to contentSkip to conversation

unexport is_console_locked

PATCH In review Adrian Bunk 4 participants 4 messages Apr 15, 2005 – Apr 24, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 unexport is_console_locked

I didn't find any possible modular usage in the kernel.

---

This patch was already sent on:
- 4 Mar 2005

kernel/printk.c renamed from kernel/printk.c.old +0 -1
@@ -675,7 +675,6 @@
 {
 	return console_locked;
 }
-EXPORT_SYMBOL(is_console_locked);
 
 /**
  * release_console_sem - unlock the console system
#1 lore raw
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

Is needed for WARN_CONSOLE_UNLOCKED().

It just happens that WARN_CONSOLE_UNLOCKED() is currently only using in vt.c, which just happens to not support modular usage.

But disabling this export would make WARN_CONSOLE_UNLOCKED() pretty useless for driver development.

So I'd suggest that we either leave this symbol exported for driver developers or we nuke WARN_CONSOLE_UNLOCKED() altogether.

Ben, do you still want it?

Quoted 10 lines
kernel/printk.c renamed from kernel/printk.c.old +0 -1
@@ -675,7 +675,6 @@
 {
 	return console_locked;
 }
-EXPORT_SYMBOL(is_console_locked);
 
 /**
  * release_console_sem - unlock the console system
#2 lore raw
Quoted 10 lines · Andrew Morton
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

Is needed for WARN_CONSOLE_UNLOCKED().

It just happens that WARN_CONSOLE_UNLOCKED() is currently only using in vt.c, which just happens to not support modular usage.

Quoted 7 lines

But disabling this export would make WARN_CONSOLE_UNLOCKED() pretty useless for driver development.

So I'd suggest that we either leave this symbol exported for driver developers or we nuke WARN_CONSOLE_UNLOCKED() altogether.

Ben, do you still want it?

Yes, I do. Please, keep it exported. On that note, I don't understand that frenzy of unexporting everything you can, I find this useless burden in general.

Ben.

#3 lore raw
Quoted 3 lines · Benjamin Herrenschmidt

Yes, I do. Please, keep it exported. On that note, I don't understand that frenzy of unexporting everything you can, I find this useless burden in general.

If we ever want to a have a semi-stable driver API (1) we need to stop exporting random symbols and move towards APIs that make sense and operate at the right level instead of poking into implementation details. Note that even without that goal only having the right primitives avaiable to drivers makes sure they use the right tool instead of copy & pasting random crap.

(1) that is changing only when we have a real need instead of all the time.