====== Record and Replay 회의 내용 정리 ======
졸업 논문 주제인 Record & Replay 에 대해서 회의한 내용을 정리했다.
====== 2007. 10. 16 ======
Record & Replay 와 관련하여 4 가지 큰 이슈가 있었다. 다음과 같다.

  - 멀티 코어 환경에서 Global Stop and Record 기능
  - I/O 상황 재현 기능
  - CPU 내부(캐쉬, 파이프라인) 기능
  - Slow replay and debug(기존의 디버거에서의 step by step 기능)
===== 나의 생각 =====
위의 4 가지 이슈 중에서 만만한 것은 하나도 없다.

  - 일단 멀티코어 환경의 H/W 가 있어야 한다는 전제가 있어야 한다. smdk2410 두 대에 uart 로 연결해서 두 대 모두를 stop 시킨다는 것은 각각의 시간차 문제(타이머 레지스터)와 통신을 위한 단계까지는 record 할 수 없다는 생각이다.
  - 여러가지 프로토콜을 가지는 I/O 디바이스가 존재할 수 있다. 단순하게 SD 메모리가 아닌 어떤 명령어를 줘야만 동작하는 디바이스에 대해서는 어떤 식으로 재현할 것인지와 중간 I/O 를 생략하고 record 되었을 당시의 상태로 만들어야 하는 것에 대한 가능 여부
  - 소프트웨어로 접근할 수 있는 방법이 없다. 캐쉬의 경우, 프로그램이 fail 이 발생한 순간과 record 하는 순간에도 계속 바뀐다. 만일 캐쉬의 값을 record 했다고 하더라도, 그 값이 올바로 쓰여졌는지 확인할 방법이 없다. 파이프라인의 경우 역시, 오퍼레이션 할 수 있는 명령어가 없다. 소프트웨어 기반하에서는 제한이 따른다.
  - 생각해 보건데, 4 가지 이슈 중에서 가장 현실성이 높아보인다. 기존의 디버거들이 유사한 방식을 사용하고 있기 때문에 그 쪽 코드를 참고할 필요가 있다.
===== 회의 결과 =====
  - 'I/O 상황 재현 기능' 에 초점을 맞춤
  - Storage, Network 에 디바이스에 대한 I/O 상황 재현
  - 절차적인 과정이 필요한 디바이스(flash) 의 경우, 좀 더 빠른 디버깅을 할 수 있는가?(예를 들면, flash 관련 함수만 수행함으로서 수행 속도를 빠르게 함)
  - 예를 들어 fwrite() 같은 함수를 application 에서 호출하면 체크포인트를 생성하는 시스템 콜이 발생하도록 함
====== 2007. 10. 23 ======
지난번 미팅에서 나온 사항에 대한 구현 가능 여부에 대해 논의했다. 
===== 나의 생각 =====
'절차적인 과정이 필요한 디바이스(flash) 의 경우, 좀 더 빠른 디버깅을 할 수 있는가?(예를 들면, flash 관련 함수만 수행함으로서 수행 속도를 빠르게 함)' 의 경우에 대해서는 중간에 연산이 이루어지고, 연산 결과를 디바이스에 write 한다면 실행결과를 일치시킬 수 없기 때문에 불가능하다. 
===== 회의 결과 =====
'임베디드 소프트웨어 상에서 디버깅을 잘하자' 라는 주제를 가지고 폭 넓게 생각한다.
====== 2007. 10. 30 ======
지난번 미팅에서 나온 사항에 대한 구체화 방법에 대해서 논의했다.
===== 나의 생각 =====
kgdb 와 kdb 를 vpos 에 포팅하고, 사용법을 쉽게 한다. 
===== 회의 결과 =====
  - kgdb 의 개념 확장, 커널 내부의 유용한 정보를 요약 / 알기쉽게 전달 / 성능 측정
  - 이벤트(인터럽트) 를 고려한 디버깅 : 인터럽트가 발생하면, 체크했다가 인터럽트를 재연하는 디버깅
====== 2007. 11. 6 ======
지난번 미팅에서 나온 사항에 대한 논의를 했다.
===== 회의 결과 =====
  - 주기마다 체크포인트를 생성하고, 인터럽트를 저장한다.
  - GDB 스타일의 디버깅 모드를 지원하고, 마지막 체크포인트 상태로 rollback 하며 앞의 부분은 skip 한다.
  - 커널 정보(쓰레드 상태, 메모리 점유율, I/O 상태, 커널 메모리, 버퍼상태)를 표시한다.
====== 2007. 11. 13 ======
===== 나의 생각 =====
  - 단순히 replay 를 해서는 비 결정적인 실행이 될 수 없다. 때문에, 각 프로세스 간에 실행 순서를 기록해야 한다.
===== 회의 결과 =====
  - 다음주 금요일 까지 졸업 논문의 목차 및 섹션을 정해올 것
  - 각 목차와 섹션에 들어갈 내용을 3 ~ 4 줄 정도로 요약할 것(구체화 방법 기술, 관련 연구)
====== 2007. 12. 10 ======
[[졸업 논문 작성을 위한 가이드 라인]] 에 대해 논의 했다.
===== 회의 결과 =====
  - '동기(문제점)' 부분이 약하다는 것과 내가 구현해야할 Record & Replay 방법이 기존의 방법과 비교해서 차별화된 점과 강점에 대한 내용이 부족하다. 
  - 'Overview' 부분에 Record & Replay 를 하기 까지의 일련의 시나리오를 작성하여 보충한다.
  - 프로그램 작성 -> 실행 및 저장(Record) -> Replay 및 디버깅
====== 2007. 12. 13 ======
메모리 스냅샷을 저장하는 데, 소요되는 시간을 어떻게 줄일 것인가에 대해서 논의 했다. 
===== 회의 결과 =====
  - 타이머 인터럽트가 발생할 때마다, 메모리 스냅샷을 저장하는 방법만으로는 익셉션이 발생했을 때의 상황을 재현하기에 부족하다(예를 들면, 2 개의 쓰레드가 하나의 공유변수를 두고 각각 ++, -- 하는 수행을 한다면, 값은 고정되지 않고 변한다).
  - 스케줄러가 호출되는 경로가 비단 타이머 인터럽트 외에도 존재하므로(s/w 인터럽트), 특정 시스템 콜 형태로 호출이 될 때마다 스냅샷을 저장한다.
  - 전체 메모리 스택을 통채로 저장하지 말고, 이벤트 정보를 저장하여 로그를 남긴다(누가, 언제, 메시지 발생시점, 메시지 수신시점등)
위의 문제들만 해결하면, 정확한 재현이 가능한가? 
====== 2008. 1. 15 ======
[[졸업 논문 작성을 위한 가이드 라인]] 수정 사항 발표 및 record 와 replay 방법에 대해서 논의 했다.
===== 회의 결과 =====
  - 메모리 스냅샷을 저장하는 방법과 이벤트 만을 저장하는 방법 중에 하나를 선택한다. 각각의 장단점을 분석하여 신중히 결정한다.
====== 2008. 1. 22 ======
새로운 이벤트 저장 방식인 Record & Replay 방법에 대해서 논의 했다.
===== 회의 결과 =====
  - 동기화, I/O 관련 이벤트, Thread create, Thread 간 통신, 메세지 큐와 관련한 이벤트 저장 필요
  - PC register 가 동일할 때, register 의 합을 구하는 것이 효율적인가? 같은 pc 값일 때, 구분 할 수 있는 카운터 변수 사용 여부
  - 트랩(trap) 코드를 삽입할 때, XIP(eXecute In Place) 에 대한 가능성 고려
====== 2008. 3. 5 ======
그 동안 구현된 항목과 앞으로 나아가야할 방향에 대해서 논의 했다.
===== 회의 결과 =====
현재 구현된 사항들은 다음과 같다. 

| Record | 구현내용 | 확인 |
| 1 | 로그(log) 정보를 메모리의 특정 영역에 저장 | 完 |
| 2 | Flash 에 로그(log) 정보를 저장 | 完 |

| Replay | 구현 내용 | 확인 |
| 1 | 재부팅 후 Flash 에서 메모리 특정 영역으로 복사 | 完 |
| 2 | 로그(log) 정보를 읽어서 리스트로 출력 | 完 |
| 3 | 리스트 선택 시에 기존의 명령어 코드 백업 | 完 |
| 4 | 트랩 코드 삽입 | 完 |
| 5 | Replay 중 트랩 발생 시 디버깅 메뉴 실행 | 完 |
| 6 | 디버깅 명령어 구현 | 完 |

하지만, Replay 를 구현하는 방법 자체에서 많은 변화가 있어야 한다는 제안이 나왔다. 
  - 현재의 Replay 하는 방법인 트랩 코드를 삽입하여 멈추는 지점까지 수행되어질 때까지 중간의 이벤트를 이용하여 수행해야 함(그래야 실제 Record 될 시의 상황과 똑같이 재현할 수 있음)
예를 들어, Thread1, Thread2 가 있을 때, 실행 순서가 1 -> 2 -> 1 라고 했을 때, 똑같이 1 -> 2 -> 1 로 되어야 한다는 것이다.
====== 2008. 3. 13 ======
정보처리학회 제출을 위한 첫번째 논문 미팅을 했다.
===== 회의 결과 =====
수정 사항은 다음과 같다.

  - 제목 : 분석(X) -> 추적(O), Analysis -> Trace
  - 저자 이름 : Woo-Jong Kim and Min-Soo Ryn, Hanyang
  - <표 1> -> Replay Mechanism 섹션으로 이동
  - 요약 수정(첫번째, 두번째 문장)

3월 17일 월요일 수정된 사항을 가지고 논문 미팅 예정
====== 2008. 3. 17 ======
정보처리학회 제출을 위한 두번째 논문 미팅을 했다. 
===== 회의 결과 =====
수정 사항은 다음과 같다.

  - 이름 수정 : Min-Soo(X) -> Minsoo(O)
  - 내용 수정 : 시점(X) -> 상황(O), Time critical(X) 삭제, (그림 1) 에 하드웨어 그림 추가

일단, 위의 수정 사항을 반영하여 학회에 제출하고, 세부사항은 최종 수정본 마감일인 4월 18일까지 수정 보완한다.
====== 2008. 3. 26 ======
앞으로의 방향에 대해서 논의했다.
여름에 우즈베키스탄에서 대한전자공학회 주최로 열리는 학회에 낼 생각이다. 하지만, 마감일이 3월 28일 까지이기 때문에, 낼 수 있을지 확실하지 않다.
===== 회의 결과 =====
다음은 교수님의 생각이다.
  - 현재 vpos 에서 구현된 record & replay 를 현재 사용되는 T32 이나 realview 에서 연동하여 사용 가능하도록 한다.
  - record & replay 를 recoplay 라고 명명한다. 
  - 다른 사람들과 연계하여 확장시킨다.
1번에 대한 얘기를 좀 더 하자면, 지금의 record & replay 기능은 디버깅 기능이 약하기 때문에, 기존의 디버거에서 vpos 이미지(vpos + 디버깅 심볼 정보 + record & replay) 를 그대로 사용하여 기존에 제공하는 많은 기능을 사용할 수 있게 한다. 
또한 현재 가장 많이 사용하고 있는 T32 나 realview 에서 사용하고 있는 IDE 프로그램과 연동하여, vpos 의 kernel-aware 정보를 볼 수 있게 한다(예를 들어, vpos 의 특정 메모리 번지에 thread 정보를 저장하여, T32 IDE 프로그램에서 그 주소를 dump 하면 그 값을 알 수 있다).
<code text>
debug_info{
int thread_number; // 현재 쓰레드 수
int current_thread;  // 현재 쓰레드 주소
..
..
..
}
</code>
====== 2008. 4. 2 ======
우즈베키스탄에서 대한전자공학회 주최로 열리는 학회에 내 논문을 영어로 번역하여 제출했다. 문제는 내가 정보처리학회에 제출했던 논문의 내용과 상당 부분 달라졌다. 
===== 회의 결과 =====
오늘 회의는 나를 제외한 3 명이 함께 했다. 일단 기존의 논문과 비교해서 달라진 것들을 얘기해보겠다.
  - 논문 제목 변경 ('Recoplay: An Effective Record-Replay Approach to Debugging Complex Embedded Software')
  - 3 가지 목적(Goal) 
    - 애플리케이션 태스크 뿐만 아니라 운영체제 또는 하드웨어로 부터 크리티컬한 이벤트 단계를 record & replay 할 수 있다.
    - 타겟 소프트웨어의 동작이 재생산될 때, 명령어(인스트럭션)레벨의 정확도를 제공할 수 있다.
    - 어떤 통합의 영향이 없이 기존의 디버거를 사용 할 수 있고 개발자는 single step 이나 breakpoint 설정과 같은 디버깅 기술을 활용할 수 있다.
  - code modifier 는 컴파일된 바이너리 상태의 파일에서 이벤트가 발생한 주소를 추가한다.
  - record & replay 에서 디버깅 명령어를 제공하지 말고 기존의 T32 나 realview 에서 제공하는 것을 사용한다.
  - divx 소스를 record & replay 로 실행하고, 각 함수별, 실행시간을 처음 실행과 replay 실행 시간을 비교한다. 
===== 나의 생각 =====
몇몇 부분을 제외하고는 내가 현재 구현한 부분과 크게 다르지 않은 것 같다. 다음은 크게 달라진 부분이다.
  - code modifier 는 컴파일 되어 나온 바이너리 상태의 파일에 이벤트가 발생한 주소를 추가한다고 했는데, 이게 현실적으로 가능한가?
  - record & replay 에서의 디버깅 명령어 모드를 없애고, 기존의 T32 와 같은 디버거에서 지원하는 명령어를 사용한다고 했는데, 그렇다면, 굳이 vpos 에 record & replay 기능을 추가할 필요가 있나? 차라리 그냥 JTAG 장비와 디버깅 툴로 잡아서 보는 편이 훨씬 낫지 않는가?
이러한 점들에 대해서 좀 더 구체적이고 조율이 필요하다.
====== 2008. 4. 25 ======
지난번 회의에 대한 나의 생각에 대한 의견을 얘기했다.
===== 회의 결과 =====
  - code modifier 는 컴파일 되어 나온 바이너리 상태의 파일에 이벤트가 발생한 주소를 추가한다고 했는데, 이게 현실적으로 가능한가? \\ -> 그냥 기존의 방식대로 처리하면 된다.
  - record & replay 에서의 디버깅 명령어 모드를 없애고, 기존의 T32 와 같은 디버거에서 지원하는 명령어를 사용한다고 했는데, 그렇다면, 굳이 vpos 에 record & replay 기능을 추가할 필요가 있나? 차라리 그냥 JTAG 장비와 디버깅 툴로 잡아서 보는 편이 훨씬 낫지 않는가? \\ -> 이해가 잘 안되지만 현재의 명령어 모드를 지원하면서, T32 디버거 툴에서 특정 메모리 주소를 덤프했을 때, 정보를 보여주는 방법으로 한다.