APP_START descriptor와 app thread | LK

QUESTION

APP_START descriptor와 app thread 단계에서 실제로 바뀌는 상태는 무엇인가?

매크로가 함수 호출을 만드는 것이 아니라 정적 descriptor를 특정 section에 둔다는 점이 핵심이다. linker boundary symbol과 실행 flag를 확인한다.

descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다. 이 문장을 기준으로 코드를 위에서 아래로 읽으면, 함수 이름을 외우는 대신 어느 시점에 어떤 상태를 신뢰할 수 있는지 판단할 수 있다.

STRUCTURE

객체와 주소가 놓이는 구조

그림 1. APP_START descriptor와 app thread에서 입력, 내부 상태, 출력의 경계

입력과 전제내부 상태외부로 공개되는 결과

01app_descriptor array

02flags

03entry function

04thread object

INVARIANT

descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다.

struct app_descriptor / app thread를 중심에 놓고 왼쪽의 입력이 어떤 검사를 거쳐 오른쪽 결과로 공개되는지 표시했다. 실제 디버깅에서는 각 블록의 주소와 크기를 로그에 대입한다.

CALL PATH

실행 흐름

그림 2. 정상 경로의 주요 호출과 상태 전달

APP_START macro

linker app section

apps_init

app init

app thread

화살표는 단순 호출 순서만 뜻하지 않는다. 각 단계가 성공을 반환할 때 다음 단계가 읽을 수 있는 상태가 무엇인지 함께 확인한다. 오류 반환이 발생하면 바로 다음 화살표로 진행하지 않고 해당 단계의 정리 경로를 따라간다.

STATE LEDGER

단계별 입력과 출력

호출 순서를 함수 이름으로만 외우지 않고, 각 단계가 무엇을 받아 무엇을 공개하는지 적은 표다. 실제 소스에서 생산 필드가 다르면 표를 고치는 방식으로 사용한다.

#	단계	진입 시 신뢰할 상태	성공 뒤 남아야 할 상태	다음 소비자
01	`APP_START macro`	부트 CPU의 동기 실행 문맥	app_descriptor array	linker app section
02	`linker app section`	APP_START macro 완료 상태	flags	apps_init
03	`apps_init`	linker app section 완료 상태	entry function	app init
04	`app init`	apps_init 완료 상태	thread object	app thread
05	`app thread`	app init 완료 상태	thread object	최종 최종 부트로더 이미지 또는 다음 stage

공통 불변 조건: descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다. 한 단계의 출력이 다음 단계의 입력 조건을 만족하지 않으면 오류가 실제로 드러난 위치보다 앞의 생산 단계부터 조사한다.

UPSTREAM SOURCE

원본 코드

아래 코드는 LK upstream 1eb9917의 app/app.c에서 1-86줄을 그대로 가져온 것이다. 설명을 위해 실제 코드를 가짜 의사 코드로 바꾸지 않았다.

commit1eb99171efae98867d4be4a5bd6479ea03f43ac9symbolvoid apps_init(void)

1/*
2 * Copyright (c) 2009 Travis Geiselbrecht
3 *
4 * Use of this source code is governed by a MIT-style
5 * license that can be found in the LICENSE file or at
6 * https://opensource.org/licenses/MIT
7 */
8#include "app.h"
9
10#include <stdio.h>
11#include <string.h>
12#include <lk/err.h>
13#include <lk/console_cmd.h>
14#include <kernel/thread.h>
15
16extern const struct app_descriptor __start_apps __WEAK;
17extern const struct app_descriptor __stop_apps __WEAK;
18
19static void start_app(const struct app_descriptor *app, bool detach);
20
21/* one time setup */
22void apps_init(void) {
23    const struct app_descriptor *app;
24
25    /* call all the init routines */
26    for (app = &__start_apps; app != &__stop_apps; app++) {
27        if (app->init)
28            app->init(app);
29    }
30
31    /* start any that want to start on boot */
32    for (app = &__start_apps; app != &__stop_apps; app++) {
33        if (app->entry && (app->flags & APP_FLAG_NO_AUTOSTART) == 0) {
34            start_app(app, true);
35        }
36    }
37}
38
39static int app_thread_entry(void *arg) {
40    const struct app_descriptor *app = (const struct app_descriptor *)arg;
41
42    app->entry(app, NULL);
43
44    return 0;
45}
46
47static void start_app(const struct app_descriptor *app, bool detach) {
48    /* dont start an app that has no entry point */
49    if (app->entry == NULL) {
50        return;
51    }
52
53    uint32_t stack_size = (app->flags & APP_FLAG_CUSTOM_STACK_SIZE) ? app->stack_size : DEFAULT_STACK_SIZE;
54
55    printf("starting app %s\n", app->name);
56    thread_t *t = thread_create(app->name, &app_thread_entry, (void *)app, DEFAULT_PRIORITY, stack_size);
57    if (detach) {
58        thread_detach(t);
59        thread_resume(t);
60    } else {
61        thread_resume(t);
62        thread_join(t, NULL, INFINITE_TIME);
63    }
64}
65
66status_t app_start_by_name(const char *name, bool detached) {
67    const struct app_descriptor *app;
68
69    /* find the app and call it */
70    for (app = &__start_apps; app != &__stop_apps; app++) {
71        if (!strcmp(app->name, name)) {
72            start_app(app, detached);
73            return NO_ERROR;
74        }
75    }
76
77    return ERR_NOT_FOUND;
78}
79
80static void list_apps(void) {
81    const struct app_descriptor *app;
82
83    for (app = &__start_apps; app != &__stop_apps; app++) {
84        printf("%s\n", app->name);
85    }
86}

LINE BY LINE

1-86줄 해설

원본에 보이는 모든 줄을 순서대로 설명한다. 빈 줄도 block 경계로 남겨, 코드와 설명의 위치가 어긋나지 않게 했다.

1/*

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

3*

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

4* Use of this source code is governed by a MIT-style

원본 주석이 'Use of this source code is governed by a MIT-style'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

5* license that can be found in the LICENSE file or at

원본 주석이 'license that can be found in the LICENSE file or at'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

6* https://opensource.org/licenses/MIT

원본 주석이 'https://opensource.org/licenses/MIT'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

7*/

원본 주석이 'block boundary'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

8#include "app.h"

#include 전처리 지시문으로 이 줄 아래의 code가 binary에 존재할지를 결정한다. architecture 또는 build stage 조건을 여닫는다. 현재 .config와 compiler의 -dD -E 출력에서 실제로 남은 branch를 확인한 뒤 line-by-line 흐름에 포함한다.

9(빈 줄)

#include "app.h"까지의 동작과 #include <stdio.h>에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

10#include <stdio.h>

11#include <string.h>

12#include <lk/err.h>

13#include <lk/console_cmd.h>

14#include <kernel/thread.h>

15(빈 줄)

#include <kernel/thread.h>까지의 동작과 extern const struct app_descriptor __start_apps __WEAK;에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

16extern const struct app_descriptor __start_apps __WEAK;

extern const struct app_descriptor __start_apps __WEAK를 선언한다. 함수 안 선언이면 현재 stack frame, file scope와 static이면 image의 data/BSS에 놓인다. 이 값이 struct app_descriptor / app thread를 직접 소유하는지 pointer만 빌리는지, 부트 CPU의 동기 실행 문맥를 벗어난 뒤에도 참조되는지 다음 대입과 callback 등록까지 따라간다.

17extern const struct app_descriptor __stop_apps __WEAK;

extern const struct app_descriptor __stop_apps __WEAK를 선언한다. 함수 안 선언이면 현재 stack frame, file scope와 static이면 image의 data/BSS에 놓인다. 이 값이 struct app_descriptor / app thread를 직접 소유하는지 pointer만 빌리는지, 부트 CPU의 동기 실행 문맥를 벗어난 뒤에도 참조되는지 다음 대입과 callback 등록까지 따라간다.

18(빈 줄)

extern const struct app_descriptor __stop_apps __WEAK;까지의 동작과 static void start_app(const struct app_descriptor *app, bool detach);에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

19static void start_app(const struct app_descriptor *app, bool detach);

static void start_app(const struct app_descriptor *app, bool detach)를 선언한다. 함수 안 선언이면 현재 stack frame, file scope와 static이면 image의 data/BSS에 놓인다. 이 값이 struct app_descriptor / app thread를 직접 소유하는지 pointer만 빌리는지, 부트 CPU의 동기 실행 문맥를 벗어난 뒤에도 참조되는지 다음 대입과 callback 등록까지 따라간다.

20(빈 줄)

static void start_app(const struct app_descriptor *app, bool detach);까지의 동작과 /* one time setup */에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

21/* one time setup */

원본 주석이 'one time setup'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

22void apps_init(void) {

apps_init 함수 정의가 시작된다. 입력은 void이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

23const struct app_descriptor *app;

const struct app_descriptor *app를 선언한다. 함수 안 선언이면 현재 stack frame, file scope와 static이면 image의 data/BSS에 놓인다. 이 값이 struct app_descriptor / app thread를 직접 소유하는지 pointer만 빌리는지, 부트 CPU의 동기 실행 문맥를 벗어난 뒤에도 참조되는지 다음 대입과 callback 등록까지 따라간다.

24(빈 줄)

const struct app_descriptor *app;까지의 동작과 /* call all the init routines */에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

25/* call all the init routines */

원본 주석이 'call all the init routines'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

26for (app = &__start_apps; app != &__stop_apps; app++) {

'for (app = &__start_apps; app != &__stop_apps; app++) {'가 목록이나 후보를 순회한다. 반복 중 struct app_descriptor / app thread를 제거·추가하는 호출이 있는지와 loop 종료 뒤 iterator가 유효한지 확인한다.

27if (app->init)

app->init를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

28app->init(app);

init(app)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

29}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

30(빈 줄)

}까지의 동작과 /* start any that want to start on boot */에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

31/* start any that want to start on boot */

원본 주석이 'start any that want to start on boot'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

32for (app = &__start_apps; app != &__stop_apps; app++) {

33if (app->entry && (app->flags & APP_FLAG_NO_AUTOSTART) == 0) {

app->entry && (app->flags & APP_FLAG_NO_AUTOSTART) == 0를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

34start_app(app, true);

start_app(app, true)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

35}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

36}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

37}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

38(빈 줄)

}까지의 동작과 static int app_thread_entry(void *arg) {에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

39static int app_thread_entry(void *arg) {

app_thread_entry 함수 정의가 시작된다. 입력은 void *arg이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

40const struct app_descriptor *app = (const struct app_descriptor *)arg;

const struct app_descriptor *app = (const struct app_descriptor *)arg를 선언한다. 함수 안 선언이면 현재 stack frame, file scope와 static이면 image의 data/BSS에 놓인다. 이 값이 struct app_descriptor / app thread를 직접 소유하는지 pointer만 빌리는지, 부트 CPU의 동기 실행 문맥를 벗어난 뒤에도 참조되는지 다음 대입과 callback 등록까지 따라간다.

41(빈 줄)

const struct app_descriptor *app = (const struct app_descriptor *)arg;까지의 동작과 app->entry(app, NULL);에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

42app->entry(app, NULL);

entry(app, NULL)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

43(빈 줄)

app->entry(app, NULL);까지의 동작과 return 0;에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

44return 0;

0를 호출자에게 반환한다. caller가 이 값을 검사한 뒤 부분 초기화된 struct app_descriptor / app thread를 정리하거나 다음 단계로 진행하는지 확인한다.

45}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

46(빈 줄)

}까지의 동작과 static void start_app(const struct app_descriptor *app, bool detach) {에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

47static void start_app(const struct app_descriptor *app, bool detach) {

start_app 함수 정의가 시작된다. 입력은 const struct app_descriptor *app, bool detach이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

48/* dont start an app that has no entry point */

원본 주석이 'dont start an app that has no entry point'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

49if (app->entry == NULL) {

app->entry == NULL를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

50return;

void를 호출자에게 반환한다. caller가 이 값을 검사한 뒤 부분 초기화된 struct app_descriptor / app thread를 정리하거나 다음 단계로 진행하는지 확인한다.

51}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

52(빈 줄)

}까지의 동작과 uint32_t stack_size = (app->flags & APP_FLAG_CUSTOM_STACK_SIZE) ? app->stack_size : DEFAULT_STACK_SIZE;에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

53uint32_t stack_size = (app->flags & APP_FLAG_CUSTOM_STACK_SIZE) ? app->stack_size : DEFAULT_STACK_SIZE;

uint32_t stack_size에 (app->flags & APP_FLAG_CUSTOM_STACK_SIZE) ? app->stack_size : DEFAULT_STACK_SIZE를 = 연산으로 반영해 현재 scope의 계산 결과를 저장한다. 주소·크기 값이면 단위와 정렬, 덧셈 overflow를 함께 검산한다. 이후 app thread 단계가 이 값을 처음 소비하는 지점을 찾는다. 실패 경로가 이 field를 이전 값으로 되돌리거나 객체 전체를 폐기하는지도 확인한다.

54(빈 줄)

uint32_t stack_size = (app->flags & APP_FLAG_CUSTOM_STACK_SIZE) ? app->stack_size : DEFAULT_STACK_SIZE;까지의 동작과 printf("starting app %s\n", app->name);에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

55printf("starting app %s\n", app->name);

printf("starting app %s\n", app->name)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

56thread_t *t = thread_create(app->name, &app_thread_entry, (void *)app, DEFAULT_PRIORITY, stack_size);

thread_t *t에 thread_create(app->name, &app_thread_entry, (void *)app, DEFAULT_PRIORITY, stack_size)를 = 연산으로 반영해 현재 scope의 계산 결과를 저장한다. 이후 app thread 단계가 이 값을 처음 소비하는 지점을 찾는다. 실패 경로가 이 field를 이전 값으로 되돌리거나 객체 전체를 폐기하는지도 확인한다.

57if (detach) {

detach를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

58thread_detach(t);

thread_detach(t)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

59thread_resume(t);

thread_resume(t)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

60} else {

원본 60번 줄의 } else {는 앞의 thread_resume(t); 결과를 받아 다음 thread_resume(t);로 넘기는 중간 연산이다. 이 줄이 바꾸는 register·field·list link를 찾고, 변경 뒤에도 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건이 유지되는지 확인한다.

61thread_resume(t);

62thread_join(t, NULL, INFINITE_TIME);

thread_join(t, NULL, INFINITE_TIME)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

63}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

64}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

65(빈 줄)

}까지의 동작과 status_t app_start_by_name(const char *name, bool detached) {에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

66status_t app_start_by_name(const char *name, bool detached) {

app_start_by_name 함수 정의가 시작된다. 입력은 const char *name, bool detached이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

67const struct app_descriptor *app;

68(빈 줄)

const struct app_descriptor *app;까지의 동작과 /* find the app and call it */에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

69/* find the app and call it */

원본 주석이 'find the app and call it'라고 기록한 줄이다. 바로 아래 구현이 이 전제와 같은 순서·단위를 사용하는지 대조한다.

70for (app = &__start_apps; app != &__stop_apps; app++) {

71if (!strcmp(app->name, name)) {

!strcmp(app->name, name)를 검사해 진행 여부를 가른다. 거짓 경로와 참 경로 중 어느 쪽이 'descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다' 조건을 보존하는지 다음 return 또는 goto까지 따라간다.

72start_app(app, detached);

start_app(app, detached)를 호출한다. 반환 결과는 현재 줄 또는 다음 return NO_ERROR;에서 검사되는 흐름이다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

73return NO_ERROR;

NO_ERROR를 호출자에게 반환한다. caller가 이 값을 검사한 뒤 부분 초기화된 struct app_descriptor / app thread를 정리하거나 다음 단계로 진행하는지 확인한다.

74}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

75}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

76(빈 줄)

}까지의 동작과 return ERR_NOT_FOUND;에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

77return ERR_NOT_FOUND;

ERR_NOT_FOUND를 호출자에게 반환한다. caller가 이 값을 검사한 뒤 부분 초기화된 struct app_descriptor / app thread를 정리하거나 다음 단계로 진행하는지 확인한다.

78}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

79(빈 줄)

}까지의 동작과 static void list_apps(void) {에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

80static void list_apps(void) {

list_apps 함수 정의가 시작된다. 입력은 void이며, 부트 CPU의 동기 실행 문맥에서 호출된다는 전제로 반환 전까지의 상태 변화를 읽는다.

81const struct app_descriptor *app;

82(빈 줄)

const struct app_descriptor *app;까지의 동작과 for (app = &__start_apps; app != &__stop_apps; app++) {에서 시작하는 동작을 나누는 빈 줄이다. 앞 블록이 만든 thread object 상태가 아래 블록의 입력으로 사용되는 경계다.

83for (app = &__start_apps; app != &__stop_apps; app++) {

84printf("%s\n", app->name);

printf("%s\n", app->name)를 호출한다. 반환값을 직접 사용하지 않으므로 이 함수가 실패를 내부 처리하는지 확인해야 한다. pointer 인자는 struct app_descriptor / app thread의 소유권을 넘기는지 호출 동안만 빌리는지 구분하고, 호출 뒤 공개되는 상태를 thread object 항목과 대조한다.

85}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

86}

현재 block, initializer 또는 호출의 경계를 닫는다. 이 지점까지 획득한 resource가 성공 경로와 실패 경로에서 대칭인지 점검한다.

DETAILS

내부 동작을 더 깊게 읽기

진입 조건을 먼저 고정한다

APP_START macro에서 들어온 실행은 부트 CPU의 동기 실행 문맥에 놓여 있다. 이때 interrupt, MMU/cache, stack, heap 중 무엇이 이미 준비되었는지 소스의 호출자까지 올라가 확인한다. 같은 함수라도 SPL, relocation 전후, app thread처럼 호출 문맥이 달라지면 허용되는 API와 지연 시간이 달라진다.

매크로가 함수 호출을 만드는 것이 아니라 정적 descriptor를 특정 section에 둔다는 점이 핵심이다. linker boundary symbol과 실행 flag를 확인한다.

중심 객체의 생성과 공개를 나눈다

이 글의 중심 객체는 struct app_descriptor / app thread다. 메모리를 확보한 시점, 필드를 채운 시점, 전역 list나 다른 subsystem에 공개한 시점을 구분한다. 공개 뒤 오류가 발생한다면 목록에서 제거하고 child, buffer, reference를 역순으로 정리하는지 확인한다.

빌드 산출물 관점에서는 최종 부트로더 이미지 안에 해당 symbol과 section이 실제로 포함되었는지도 map과 objdump로 검증한다.

주소, 크기와 정렬을 계산한다

부트 코드의 오류는 논리보다 주소 계산에서 먼저 드러나는 경우가 많다. source range, destination range, header가 말하는 payload size, block 또는 page 단위를 표로 적고 각 구간의 끝 주소를 직접 계산한다. 끝 주소는 start + size - 1인지 exclusive end인지 API 계약을 확인한다.

descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다.

성공 flag와 실제 완료 시점을 맞춘다

linker app section → apps_init → app init 구간에서는 부분 초기화 상태가 생길 수 있다. flag, list insertion, callback 등록, storage write 완료 중 무엇이 성공의 기준인지 찾는다. hardware write나 DMA가 포함되면 함수 반환과 장치 완료가 같은 시점인지도 확인한다.

다른 CPU, interrupt handler, USB completion 또는 shell command가 상태를 관찰할 수 있다면 memory ordering과 lock 범위도 함께 읽는다.

마지막 handoff의 계약을 적는다

정상 경로는 app thread에서 끝난다. 이 단계가 함수 반환인지, scheduler 전환인지, 다른 image로의 비복귀 분기인지 구분한다. 비복귀 handoff라면 cache clean/invalidate, interrupt disable, 장치 quiesce, argument register와 FDT 또는 image address가 최종 점검 항목이다.

반환하는 경로라면 caller가 오류와 부분 성공을 구분하고 다음 후보 또는 복구 경로를 선택하는지 확인한다.

IMPLEMENTATION NOTES

구현을 읽을 때 놓치기 쉬운 부분

APP_START는 함수 호출이 아니라 정적 descriptor 생성이다

macro가 app name, init entry, flags와 stack size를 linker section에 놓고 startup code가 section 범위를 순회한다. object가 link되지 않거나 section KEEP가 빠지면 source에 app이 있어도 실행되지 않는다.

map에서 descriptor와 문자열, function pointer가 같은 image에 남았는지 확인한다.

app init을 현재 thread에서 할지 새 thread에서 할지 구분한다

flag에 따라 bootstrap 문맥에서 직접 init하거나 전용 thread를 만들 수 있다. 전용 thread entry가 참조하는 descriptor와 argument는 image 수명 동안 유효하지만 init 함수의 stack 지역 데이터는 넘길 수 없다.

stack size와 priority가 제품 latency와 overflow 위험을 결정하므로 default를 그대로 쓰지 않는다.

app 간 순서는 dependency framework가 아니다

section 순서나 등록 순서에 의존해 다른 app의 global 상태를 읽으면 link 순서 변경에 깨진다. 명시적 init hook level, event 또는 service-ready flag로 dependency를 표현한다.

특정 app을 build에서 제거한 뒤 consumer가 명확히 비활성화되는지 시험한다.

OBJECT LIFETIME

객체와 수명

대상	만들어지는 시점	유효 범위	확인할 조건
`struct app_descriptor / app thread`	linker app section	app thread 또는 오류 정리 완료까지	descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다.
입력 buffer / metadata	APP_START macro	parse와 검증이 끝날 때까지	길이, 정렬, 소유권, 변조 가능성
등록된 list / descriptor	apps_init	subsystem 종료 또는 image handoff까지	이중 등록, dangling pointer, 오류 unwind
hardware 또는 persistent state	실제 write/probe가 완료된 뒤	reset 또는 명시적 해제·갱신까지	flush, timeout, 전원 차단, rollback
`최종 부트로더 이미지`	link/image 생성 시점	다음 stage가 새 image로 교체할 때까지	load address, entry, section과 header 일치

FAILURE PATH

실패 지점과 증상

#	조건	관찰되는 증상	먼저 볼 단계
01	section KEEP 누락	app가 조용히 사라짐	linker app section
02	descriptor 정렬 오류	다음 entry 오독	apps_init
03	app thread stack 부족	초기화 후 crash	app init

로그가 끊긴 마지막 함수만 고치지 않는다. 그 함수가 받은 주소, size, flag가 만들어진 앞 단계까지 올라가고, 오류 뒤 등록 객체와 hardware 상태가 남았는지도 확인한다.

EVIDENCE

소스 밖에서 확인할 증거

소스 해석은 실제 빌드 산출물과 target 로그로 닫아야 한다. 아래 명령의 보드 이름과 toolchain prefix는 사용 중인 빌드 환경에 맞게 바꾼다.

#	목적	명령 또는 계측	판정 기준
01	빌드 구성	`make <project> -j1`	platform, target, app 선택과 linker 입력을 로그로 남긴다.
02	symbol과 주소	`nm -n build-*/lk.elf \| grep 'void apps_init'`	init hook, app descriptor와 함수가 어느 주소에 놓였는지 확인한다.
03	어셈블리 대조	`objdump -drS build-*/lk.elf`	thread 전환과 interrupt disable 구간의 실제 명령을 확인한다.
04	초기화 순서	`init level 전후에 current_time_hires()와 함수 이름 기록`	level 내부 순서와 지연을 serial log로 남긴다.
05	문맥 확인	`current_thread, interrupt state, stack pointer 기록`	함수가 bootstrap thread인지 scheduler 이후 thread인지 구분한다.

LAB

직접 확인할 실험

01
map에서 apps section 시작/끝 확인
linker app section 진입 전후에 app_descriptor array의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다. 조건이 처음 깨지는 줄을 기록한다.
02
APP_START 하나 추가 후 descriptor 수 비교
apps_init 진입 전후에 flags의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다. 조건이 처음 깨지는 줄을 기록한다.
03
APP_FLAG_DONT_START_ON_BOOT 변경 효과 확인
app init 진입 전후에 entry function의 주소·크기·반환값과 timestamp를 함께 남긴다. 결과는 정상 부팅 여부로 끝내지 말고 descriptor 범위에 포함된 각 app는 설정된 실행 방식에 따라 정확히 한 번 초기화되어야 한다. 조건이 처음 깨지는 줄을 기록한다.

PRIMARY REFERENCES

원문과 다음 글

app/app.cupstream 1eb9917 원본 파일 LK source tree기준 commit 1eb99171efae