// SPDX-License-Identifier: GPL-2.0
/*
* Generate definitions needed by the preprocessor.
* This code generates raw asm output which is post-processed
* to extract and format the required data.
*/#define __GENERATING_BOUNDS_H
/* Include headers that define the enum constants of interest */#include<linux/page-flags.h>#include<linux/mmzone.h>#include<linux/kbuild.h>#include<linux/log2.h>#include<linux/spinlock_types.h>intmain(void){/* The enum constants to put into include/generated/bounds.h */DEFINE(NR_PAGEFLAGS,__NR_PAGEFLAGS);DEFINE(MAX_NR_ZONES,__MAX_NR_ZONES);#ifdef CONFIG_SMP
DEFINE(NR_CPUS_BITS,ilog2(CONFIG_NR_CPUS));#endif
DEFINE(SPINLOCK_SIZE,sizeof(spinlock_t));/* End of constants */return0;}
위의 주석을 보면 알겠지만, kernel/bounds.c가 원본이 되는 소스고, 빌드 과정 중에 include/generated/bounds.h가 생성되었기 때문에 수정하지 말라는 것을 확인할 수 있다.
여기서 몇가지 질문이 생겼다.
include/generated/bounds.h 헤더는 언제 생성되었는가?
kernel/bounds.c에서 어떻게 include/generated/bounds.h가 생성되었을까?
왜 직접 헤더에서 DEFINE() 매크로를 사용하지 않고 헤더를 생성해야 했을까?
include/generated/ 헤더 생성 과정
include/generated/의 헤더를 여러 소스에서 사용하고 있기 때문에, 해당 헤더들의 생성 시기는 본격적인 커널 구성 소스들의 컴파일 이전에 생성되어야 한다.
일단 해당 문제를 제기한 include/generated/bounds.h 관련해서 검색해 본 결과 Kbuild에서 힌트를 찾을 수 있었다.
bounds-file := include/generated/bounds.h는 생성될 헤더를 변수로 선언하고 있다.
always-y := $(bounds-file)는 해당 헤더가 언제나 생성되어야 하는 목록에 추가되는 것으로 보인다. (여기에서는 :=로 할당되어있지만, 아래 헤더들을 보면 +=로 추가하는 것을 확인할 수 있다.)
targets := kernel/bounds.s는 빌드 타겟에 어셈블리 소스 코드가 추가되는 것으로 보인다. (여기에서는 :=로 할당되어있지만, 아래 헤더들을 보면 +=로 추가하는 것을 확인할 수 있다.)
$(bounds-file): kernel/bounds.s FORCE는 헤더를 만들기 위해선 어셈블리 소스를 필요로 한다는 것을 확인할 수 있다.
$(call filechk,offsets,__LINUX_BOUNDS_H__)는 헤더를 만들기 위한 명령어/함수를 서술하는 것으로 보인다.
일단 kernel/bounds.s → include/generated/bounds.h 순으로 헤더가 생성되는 것으로 보인다. 하지만 리포지터리 내에 kernel/bounds.s가 없으며, 심지어 .gitignore에서 *.s가 있는 것으로 보아, kernel/bounds.s는 생성된 어셈블리 코드로 보인다. (arch/arm64/kernel/head.S 같이 직접 작성한 어셈블리 코드의 확장자는 대문자 S로 구분하는 것 같다.)
위의 targets가 어디서 컴파일되는지는 바로 파악되지 않지만, kernel/bounds.c → kernel/bounds.s → include/generated/bounds.h 순으로 생성된다고 예측할 수 있다.
어셈블리 코드에서 헤더 생성 과정
일단 헤더 생성 과정은 $(call filechk,offsets,__LINUX_BOUNDS_H__)인 것을 확인했으니, 어셈블리 코드를 헤더로 생성하는 과정을 찾아보자. filechk,offsets 관련 코드를 검색해 본 결과 scripts/Makefile.lib에서 예상되는 함수를 찾았다.
# Default sed regexp - multiline due to syntax constraints## Use [:space:] because LLVM's integrated assembler inserts <tab> around# the .ascii directive whereas GCC keeps the <space> as-is.define sed-offsets
's:^[[:space:]]*\.ascii[[:space:]]*"\(.*\)".*:\1:; \
/^->/{s:->#\(.*\):/* \1 */:; \
s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; \
s:->::; p;}'endef
# Use filechk to avoid rebuilds when a header changes, but the resulting file# does notdefine filechk_offsets
echo"#ifndef $2";\
echo"#define $2";\
echo"/*";\
echo" * DO NOT MODIFY.";\
echo" *";\
echo" * This file was generated by Kbuild";\
echo" */";\
echo"";\
sed -ne $(sed-offsets) < $<;\
echo"";\
echo"#endif"endef
#ifndef __LINUX_BOUNDS_H__
#define __LINUX_BOUNDS_H__
/*
* DO NOT MODIFY.
*
* This file was generated by Kbuild
*/#define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS */#define MAX_NR_ZONES 4 /* __MAX_NR_ZONES */#define NR_CPUS_BITS 8 /* ilog2(CONFIG_NR_CPUS) */#define SPINLOCK_SIZE 4 /* sizeof(spinlock_t) */#endif
scripts/Makefile.lib를 확인해 보면 어셈블리 코드의 .ascii로 시작하는 부분을 정규표현식으로 찾아서, 순서대로 문자열을 추출하여 헤더의 정의 방식 대로 출력하게 하는 것을 볼 수 있다.
어셈블리 코드의 생성
이전의 targets := kernel/bounds.s에서 설정한 targets가 어디까지 연결되고, 어디서 사용되는지는 완전히 확인하지 못했지만, 어셈블리 소스 파일을 생성하기 위한 패턴은 scripts/Makefile.build에서 확인할 수 있었다.
110
111
112
113
114
115
116
117
# Compile C sources (.c)
# ---------------------------------------------------------------------------
quiet_cmd_cc_s_c= CC $(quiet_modtag)$@cmd_cc_s_c=$(CC)$(filter-out $(DEBUG_CFLAGS), $(c_flags))$(DISABLE_LTO) -fverbose-asm -S -o $@ $<
$(obj)/%.s:$(src)/%.cFORCE$(call if_changed_dep,cc_s_c)
어셈블리 코드로 컴파일해야 하는 타겟은 cmd_cc_s_c를 사용하게 될텐데, 여기서 사용되는 gcc 옵션들 중 어셈블리 관련 옵션을 확인해보면 아래와 같다.
-S Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input file specified. By default, the assembler file name for a source file is made by replacing the suffix ‘.c’, ‘.i’, etc., with ‘.s’. Input files that don’t require compilation are ignored.
-fverbose-asm Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those who actually need to read the generated assembly code (perhaps while debugging the compiler itself). -fno-verbose-asm, the default, causes the extra information to be omitted and is useful when comparing two assembler files.
-S로 어셈블리 코드 수준에서 컴파일을 멈추게 하고, -fverbose-asm에서 전처리기의 결과를 생략하지 말고 모두 출력하게 하고 있다. 이를 통해 DEFINE()으로 선언된 상수를 .ascii 형태로 읽을 수 있었던 것이다.
DEFINE()의 정의를 보면, 강제로 .ascii 형태의 문자열 상수화 하는 것을 확인할 수 있다.
헤더가 생성되는 과정은 확인할 수 있었지만, 왜 이런 식으로 헤더를 생성해야 하는 지에 대한 부분은 코드 상에 나와있지 않았다. 해당 코드에 관련 내용을 git blame으로 확인해 본 결과 의미있는 commit을 찾을 수 있었다.
kbuild: create a way to create preprocessor constants from C expressions
The use of enums create constants that are not available to the preprocessor
when building the kernel (f.e. MAX_NR_ZONES).
Arch code already has a way to export constants calculated to the preprocessor
through the asm-offsets.c file. Generate something similar for the core
kernel through kbuild.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
해당 commit은 kernel/bounds.c를 추가할 때 생성된 여러 commit 중 하나로 보인다. (해당 commit의 변경분 만으로는 kernel/bounds.c에 들어갈 내용이 모자라다.)
커널에서는 상수 정의에 #define 외에 enum을 통해 정의하기도 한다. enum은 선언 순서에 따라 값을 변경하면서 선언할 수 있기에 #define보다 자주 볼 수 있다.
여기 내용에서 보듯, enum으로 정의된 상수를 전처리기에서 사용하고자 할 때 컴파일 순서에 의해 enum 상수 값을 전처리기가 알 수 없다는 문제가 생긴다.
enumzone_type{/*
* ZONE_DMA and ZONE_DMA32 are used when there are peripherals not able
* to DMA to all of the addressable memory (ZONE_NORMAL).
* On architectures where this area covers the whole 32 bit address
* space ZONE_DMA32 is used. ZONE_DMA is left for the ones with smaller
* DMA addressing constraints. This distinction is important as a 32bit
* DMA mask is assumed when ZONE_DMA32 is defined. Some 64-bit
* platforms may need both zones as they support peripherals with
* different DMA addressing limitations.
*
* Some examples:
*
* - i386 and x86_64 have a fixed 16M ZONE_DMA and ZONE_DMA32 for the
* rest of the lower 4G.
*
* - arm only uses ZONE_DMA, the size, up to 4G, may vary depending on
* the specific device.
*
* - arm64 has a fixed 1G ZONE_DMA and ZONE_DMA32 for the rest of the
* lower 4G.
*
* - powerpc only uses ZONE_DMA, the size, up to 2G, may vary
* depending on the specific device.
*
* - s390 uses ZONE_DMA fixed to the lower 2G.
*
* - ia64 and riscv only use ZONE_DMA32.
*
* - parisc uses neither.
*/#ifdef CONFIG_ZONE_DMA
ZONE_DMA,#endif
#ifdef CONFIG_ZONE_DMA32
ZONE_DMA32,#endif
/*
* Normal addressable memory is in ZONE_NORMAL. DMA operations can be
* performed on pages in ZONE_NORMAL if the DMA devices support
* transfers to all addressable memory.
*/ZONE_NORMAL,#ifdef CONFIG_HIGHMEM
/*
* A memory area that is only addressable by the kernel through
* mapping portions into its own address space. This is for example
* used by i386 to allow the kernel to address the memory beyond
* 900MB. The kernel will set up special mappings (page
* table entries on i386) for each page that the kernel needs to
* access.
*/ZONE_HIGHMEM,#endif
ZONE_MOVABLE,#ifdef CONFIG_ZONE_DEVICE
ZONE_DEVICE,#endif
__MAX_NR_ZONES};
중간에 보면 CONFIG_ZONE_DMA, CONFIG_ZONE_DMA32, CONFIG_HIGHMEM, CONFIG_ZONE_DEVICE의 정의 여부에 따라 enum 중간 값이 추가되거나, 제거되기도 한다. 그리고 마지막으로 __MAX_NR_ZONES는 이전까지 enum 선언된 값의 개수에 따라 바뀐다.
MAX_NR_ZONES가 사용되는 코드를 검색해 보면 코드 내 상수로 사용되는 것이 대부분이지만, 아래와 같이 해당 값이 전처리기에서 사용되는 경우도 존재한다.
/*
* When a memory allocation must conform to specific limitations (such
* as being suitable for DMA) the caller will pass in hints to the
* allocator in the gfp_mask, in the zone modifier bits. These bits
* are used to select a priority ordered list of memory zones which
* match the requested limits. See gfp_zone() in include/linux/gfp.h
*/#if MAX_NR_ZONES < 2
#define ZONES_SHIFT 0
#elif MAX_NR_ZONES <= 2
#define ZONES_SHIFT 1
#elif MAX_NR_ZONES <= 4
#define ZONES_SHIFT 2
#elif MAX_NR_ZONES <= 8
#define ZONES_SHIFT 3
#else
#error ZONES_SHIFT -- too many zones configured adjust calculation
#endif
다른 부분은 코드 내 상수로만 들어가는 것이기 때문에 enum으로 정의된 __MAX_NR_ZONES를 사용해도 큰 문제가 되지 않았다. 하지만 위의 헤더와 같이 MAX_NR_ZONES의 값이 전처리기 시기에 숫자로 치환되지 않으면 해당 부분을 의도한 대로 전처리기 해석이 불가능하다. (값의 크기를 비교해야 되는데 문자열로 치환되기 때문)
즉, 해당 commit에서 언급한 것 처럼 enum으로 생성한 상수를 전처리기에서 사용하기 위해서는 해당 정의에 따른 값으로 완전히 치환해야 했던 것이고, 이를 위해 따로 소스 코드를 생성하고, 컴파일하여 그 내용을 바탕으로 다시 헤더를 생성한 것이다.
