Compilazione modulo Kernel e KBUILD_NOPEDANTIC

Question

Ho notato che i kernel recenti (a partire da 2.16.24?) Non mi piacciono se lo CFLAGS viene modificato nel file Kbuild del modulo esterno. Se CFLAGS è cambiato ti verrà rilasciato il seguente errore dal sistema Linux kernel kbuild:

scripts/Makefile.build:46: *** CFLAGS was changed in "/some/path". Fix it to use EXTRA_CFLAGS. Stop. 

Da here:

Moduli esterni hanno in alcuni casi modifed opzione gcc modificando CFLAGS. Questo non è mai stato documentato e era una cattiva pratica.

Ulteriori email da LKML.

Perché è una cattiva idea? Cos'è razionale?

Answer 1

I makefile di Linux creano CFLAGS in un modo appropriato per il kernel.
Ignorare CFLAGS significa aggiungere alcuni flag e rimuovere alcuni flag. Alcuni dei flag rimossi potrebbero essere importanti per la corretta compilazione.

Answer 2

Prima di tutto, vale la pena ricordare che lo EXTRA_CFLAGS è stato ritirato qualche tempo fa e sostituito da ccflags-y. È possibile leggere l'intenzione di ccflags-y in Documentation/kbuild/makefiles.txt, sezione 3.7.

Fondamentalmente, questa variabile consente di aggiungere le impostazioni all'insieme di flag di compilazione C, nell'ambito del file a cui è assegnato solo. Non è necessario modificare i flag globali, perché lo potrebbe avere un impatto globale oltre il proprio makefile, che è considerato una cattiva pratica. Il controllo che hai menzionato verifica che, in effetti, le bandiere globali non sono state modificate dai makefile inclusi.

È interessante verificare come ccflags-y, precedentemente noto come EXTRA_CFLAGS, venga utilizzato nel processo di compilazione. Tracciare alcuni punti rilevanti (ma non tutti, perché questo è lasciato come esercizio al lettore ;-)) mostra il seguente:

EXTRA_CFLAGS può ancora essere utilizzato, secondo scripts/Makefile.lib

1 # Backward compatibility 
2 asflags-y += $(EXTRA_AFLAGS) 
3 ccflags-y += $(EXTRA_CFLAGS) 

Lo stesso file mostra come ccflags-y finisce nelle bandiere C di compilazione (e inoltre si dimostra che avete un'altra variabile a vostra disposizione, chiamato CFLAGS_<filename>.o):

104 orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \ 
105     $(ccflags-y) $(CFLAGS_$(basetarget).o) 
106 _c_flags  = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags)) 
... 
133 __c_flags  = $(_c_flags) 
... 
147 c_flags  = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)  \ 
148     $(__c_flags) $(modkern_cflags)       \ 
149     -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) 

Poi nel scripts/Makefile.build, comp regola ilation è definito:

234 cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< 

Si noti che questi sono tutti in modo ricorsivo variabili espanse, utilizzando = e non :=, il che significa che il proprio valore ccflags-y viene inserito nelle bandiere C quando si definisce nel proprio makefile.

Finalmente circa KBUILD_NOPEDANTIC, che si menziona nel titolo ma non nella domanda effettiva.Questo test per valore modificato di CFLAGS può essere disabilitata dando KBUILD_NOPEDANTIC alcun valore - vedere scripts/Makefile.build

47 ifeq ($(KBUILD_NOPEDANTIC),) 
48   ifneq ("$(save-cflags)","$(CFLAGS)") 
49     $(error CFLAGS was changed in "$(kbuild-file)". Fix it to use ccflags-y) 
50   endif 
51 endif 

I file di riferimento in questa risposta sono stati tutti recuperati oggi.

Ora ... non essendo un esperto in questo settore e guardando oltre i makefile dopo aver scritto tutta questa storia, c'è una cosa che non capisco neanche io. Mi sembra che CFLAGS non sia usato nel sistema di build (non implicitamente, né esplicitamente), ma è KBUILD_CFLAGS. Quindi mi chiedo se questo controllo per le modifiche in CFLAGS in realtà dovrebbe essere un controllo per le modifiche in KBUILD_CFLAGS invece.