spin_lock_irqsave, gcc und SMP vs Einprozessormaschinen

[belmont]

Hallo, ich bin gerade dabei mISDN_v2 (socket branch) deb's zu bauen.

Da ich auch zu Teil an mISDN z.Z. etwas mitarbeite, ist mit beim bauen der deb's eine Frage zu spin_lock_irqsave aufgetreten. Und zwar zu deren
portiertbarkeit in deb's also Binärpakete. Den im Buch "Linux Treiber entwickeln" steht dazu folgendes:

"Glücklicherweise muss sich der Treiberentwickler um die Differenzierung – Interruptsperre auf Einprozessormaschinen, Spinlocks bei SMP – keine Gedanken machen. Denn tatsächlich kann er in Linux Spinlocks scheinbar auch auf Einprozessormaschinen verwenden. Für ihn transparent expandiert der Compiler die zugehörigen Makros automatisch zu einer einfachen Interruptsperre." (1)

Heist dass, wenn ich die deb's auf einer Einprozessormaschine compile, dann sind die Binärpakete auf SMP Maschine nicht zu gebrauchen, da der gcc aus den Spinlocks einfache Interruptsperren macht?

Sollte man also Binärpakete möglichst immer auf einer SMP Maschine bauen, damit diese dann "dual use" sind?

Kristijan

(1) http://ezs.kr.hs-niederrhein.de/Treiber ... chutz.html

[Spasswolf]

Das Makro spin_lock_irqsave ist unterschiedlich definiert, je nachdem ob CONFIG_SMP in der Kernel Konfiguration gesetzt ist oder nicht. Baust du die Pakete gegen einen nicht SMP Kernel (der 486 Debian) wird die Nicht SMP Version der Makros verwendet, baust du sie gegen einen SMP Kernel wird die SMP Version verwendet.
Je nachdem ob CONFIG_SMP gesetzt ist, wird in include/linux/spinlock.h der entsprechende Header eingebunden:

Code: Alles auswählen

/*
 * Pull the _spin_*()/_read_*()/_write_*() functions/declarations:
 */
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
# include <linux/spinlock_api_smp.h>
#else
# include <linux/spinlock_api_up.h>
#endif

[belmont]

Ok danke, verstehe. Das heißt, wenn ich deb's mit Kernel Modulen baue, dann diese mittels der Depend-Zeile in der control Datei an der jeweiligen Kernel
binden, auf welchen diese kompiliert wurden damit es passt.

[armin]

Im Normalfall werden Kernelmodule nicht binär ausgeliefert, sonder in einer Form, die es erlaubt, das Modul mit dem module-assistant zu bauen.