My Diary (2nd)

PC에서 ubuntu 8.04 또는 그 이후 version을 설치하면 (아마 이전 version도 될 듯)
cups-pdf라는 package가 설치된다. adobe PDF writer같은 프로그램인데, 설치하면 PDF라는 printer가 생긴다. 그리로 출력하면 ${HOME} directory에 PDF directory가 생기면서 그 아래에 PDF file이 생기는 편리한 놈이다.

몇일전 PC가 맛가서 이전 PC에 이것저것 복구해서 쓰고 있는데,
이게 동작하지 않는거다. 분명히 출력했는데, 파일은 없는...
이상해서 log를 보니까 다음과 같이 나오면서 출력이 안되는 거였다.

root@moria:/var/log/cups# tail -f cups-pdf_log
Thu Mar 19 11:11:50 2009  [ERROR] failed to create directory (/mnt/hda3/tolkien/PDF)
Thu Mar 19 11:11:50 2009  [ERROR] failed to create user output directory (/mnt/hda3/tolkien/PDF)
Thu Mar 19 11:13:29 2009  [ERROR] failed to set file mode for PDF file (non fatal) (/mnt/hda3/tolkien/PDF/FormattingAnAndroidSdCard___WRSeng___TWiki.pdf)
Thu Mar 19 11:18:21 2009  [ERROR] failed to set file mode for PDF file (non fatal) (/mnt/hda3/tolkien/PDF/PPR_Test_Page.pdf)

원인은 apparmor의 문제. CUPS쪽 security를 담당하는 놈이라고 한다.
(지금까지 이런게 있는 줄도 몰랐다. --;;;)
나는 용량증설도 있고, 관리의 편리함때문에 /home/tolkien -> /mnt/hda3/tolkien 으로 link를 걸어놨는데, apparmor가 link를 처리하지 않아서 생기는 문제였다.
/etc/apparmor.d/usr.sbin.cupsd 에 다음 두줄 추가하고 apparmor를 다시 시작하니까 깔끔하게 된다.

  /mnt/hda3/tolkien/PDF/ rw,
  /mnt/hda3/tolkien/PDF/* rw,

크로스컴파일 환경 구축하기 - Monaca님의 글

개발 tool은 신뢰할 수 있어야 한다.

Embedded Linux System을 개발하는데, 마주치는 bug는
이들과 싸워야 하는 programmer에게 gcc와 같은 기본적인 toolchain에 있는 버그는 악몽과도 같다.

단순히 build가 되는 조합만 찾아서 build하면 ToolChain을 쓸 수 있는 것이 아니다.
그 다음에 반드시 해야 하는 것은 ToolChain에 대한 검증이다.

GNU toolchain에서는 이것을 regression test라고 부른다. 이 test는 많은 항목으로 이루어져 있고, 결과는 성공, 실패, 예상한 실패, 예상하지 못한 실패에 대한 항목 숫자로 나온다. (물론 실패에 대한 log도 제공한다.)

이 regression test는 native toolchain은 검증하기 쉽다. test tool을 설치하고 돌리면 그만이다. 그런데, cross toolchain은 그게 안된다. 각 file를 compile해서 해당 target에 돌린다음 그 결과를 봐야 하기 때문이다. 2만 항목이 넘는 것을 전부 수동으로 돌릴 수 없다. 따라서, 해당 tool에 대한 약간의 hacking과 host system 준비, NFS가 가능한 target board 환경이면 하루정도 꼬박 돌리면 결과를 볼 수 있다.

그리고, 그 결과를 분석해야 한다. 특히, 예상하지 못하게 성공하거나 실패한 항목에 대한 대비를 세워야 한다. 그 항목이 자주 쓰이는가, 관련 patch는 존재하는가, 그것을 피하는 방법은 있는지. patch가 있다면 patch해서 build한 다음에 문제는 없는지, 다른 부정적 효과는 없는지. 다시 regression test를 돌려봐야 한다.
그리고, gcc mailing list를 계속 monitor해서 현재 쓰고 있는 toolchain 조합에 보고된 문제가 없는지 확인해야 한다. 그 문제가 단순하게 정리가 되면 다음 gcc release에 test 항목으로 추가된다.

위 방법대로 하면 약 10개정도 내외의 bug를 지닌 ToolChain이 나온다. 남아 있는 bug들은 잘 쓰이지 않는 재현경로를 사용해서 발생하는 것들이다. 정석대로라면 toolchain에 README.BUG와 같은 file을 만들어서 해당 내용 및 재현방법을 기술해야 한다. 이에 대해서 피할 수 있는 방법까지 담고 있으면 더 좋다.
하지만, 그런 내용을 담은 file을 같이 배포하는 SDK를 보지 못했다.

결국 이 모든 악몽에서 벗어나는 방법은 검증된 ToolChain을 쓰는 것이다. 다음과 같은 방법으로 입수가 가능하다.

Ten Weeks 제도
20% 프로젝트, 성공의 조건
피자 두판의 법칙

(위에 것은 그냥 link다. 본 글하고 약간의 상관은 있을 것같다.)

꿈을 꾸었다. A/B팀과 13번 자리에 대한.

가. A/B팀은 어떤 업무에 대한 책임을 가지고 수행하는 팀과
그 팀을 지원 또는 대체하는 팀이라는 개념이다.

미 해군은 승무원을 A팀, B팀으로 나누어서 운영한다고 한다.
아마 미 핵잠수함은 비싼 장비고,
사람들을 장시간 물속에 갇혀지내게 할 수 없어서.라는 이유가 아닐까 생각한다.
A, B팀간 구별은 없다.라고 생각한다.

영화 "아폴로 13호"에 보면 우주선 승무원도
한번 발사시 두개 팀으로 나누어서 운영한다.
떠날 팀중에 문제가 생기면 같은 모듈로 갈아치우거나
팀을 바꾼다. (예비로 정해진) B팀은 또 다른 일정이 있는 A팀인 거다.

나. 13번 자리.라는 것이 있다.
(왜 하필 13인지 모르겠다. 꿈에서 L모씨가 그렇게 설명했다.)
일종의 블랙홀.
어떤 업무를 수행하는 사람 또는 업무 그 자체인데,
제대로 진행이 되지 않고 있고
더 큰 문제는 교체할 수 없는 상황인거다.

다. 이 꿈을 오늘 새벽에 꾸고 바로 깼다.
아마 요즘 내 고민중 하나인 어떻게 팀을 구성할까.에 대한
무의식적인 해답 도출 노력의 일부가 아닐까.

코딩도 글쓰기... - 시즈하님의 글


몇가지 coding style에 대한 글의 link를 적어놓습니다.
Style Guide for Python Code
리눅스 코리아 PHP Coding Standard

CodingStyle, NamingRule에 관해서는
밤새 토론해도 결론이 나지 않을 내용중 하나라고 생각합니다.
이럴 때 필요한 것은 총대를 메는 사람.

그들 후보는...
1. 팀장. (직급으로 누른다.)
2. 시즈하. (패기와 열정으로 앞도한다.)
3. 사장님. (Nice!)

라고 생각하면 source의 bug라고 생각한다.
하지만, 다음과 같은 경우도 결국 memory 부족을 유발한다.

BUG중에서 잡기 힘든 유형이다.
항상 발생하는게 아니고 여러번 반복해야 발견이 되니 몸이 아주 귀찮다. (그렇다고 log를 남길 검증자들이 아니다. 현상만 보고한다.)

그렇다고 저 현상을 찾기 위해 몸이 수고할 tolkien이 아니지. 자동화 tool 만든다고 mz_test 만들다가 급한 것같아서 일단 자동 wakeup한다고 rtcwakeup code 손보다가 삽질을 했지만, 결국 자동화 code 돌린지 1시간만에 원인 발견.

돌린지 17번째 횟수에서 한번 발견, touch interrupt가 들어오지 않는 것을 확인하고 다시 한번 돌려서 31번째 다시 현상 재확인.
registers.o를 올려서 이것저것 확인해보니...

# cat /proc/cpu/registers/GAFR2_U
0x01000002
# cat /proc/cpu/registers/GPDR2
0x0ec1ffff
# cat /proc/cpu/registers/GPLR2
0x7501cf5c

# cat 76-AC97_WM9705_TS1
0xe020
0b.1110.0000.0010.0000
15 - POLL
14:12 - ADC_SEL (BMON)
7: 4 - DEL (83.8us)
# cat 78-AC97_WM9705_TS2
0xe281
0b.1110.0010.1000.0001
15:14 - RPR (running)
13 - RPR (AC-line & wm9712 auto-wake-up)
9 - WAIT (until old data has been read)
8 - PIL (400uA)
1 - RPU (64k-Ohm)

이런... battery 값을 안 가져갔네? 0x78 register에 WAIT이 setting되 어있으니 이전 값을 가져가기 전까지는 새로운 값을 가져올 수 없다.라는 것이다. (그전에는 h/w팀의 똥인 줄 알았다.)

이런이런... 부랴부랴 code patch를 했다.
sleep/wakeup 구간에 진입했을때 ADC-request가 들어오면 그냥 빠져나오게 하고 혹시나 해서...

ret = ts_reg_read(AC97_WM9705_DAT);

로 강제적으로 값을 읽어버리게 하고 등등... 해서 다시 test를 돌리니까 잘 되는 것같아 기분이 좋았다. ^^

근데, 지금 생각해보니...

clear_bit(WM9705OTH_RUNNING, &wm9705bat.flag);
clear_bit(WM9705OTH_RUNNING, &wm9705bat_type.flag);

같은 code는 두번 register되는 문제가 있지 않을까? 응?

wake_up_interruptible(&info->wq);
wake_up_interruptible(&info->type_wq);

이렇게 해서 깨어나면 error 처리해야 iom_v2란 놈이 제대로 처리할텐데 왠지 불안하다. --;;;
에구에구, 출근해서 고쳐야겠네. (흑... 그리고 다시 test... T.T 밤새 걸어놓은게 무의미해짐.)

좌우간 자동화 test tool은 필요하다. 게으른 자에게는...

drivers/char/sa1100-rtc.c에서 open()쪽을 보면...

if (test_and_set_bit (1, &rtc_status))
return -EBUSY;
rtc_irq_data = 0;

짜잔~ 다른 놈이 open하고 있으면 다시는 안 열린다.
RTC 동작방식을 생각하면 일견 이해가 되지만, 문제는 debugging...
sleep/wakeup에 문제가 있어 debugging하려니 영~불편하군.

임시로 return -EBUSY를 skip하게 만들어서 kernel을 올려서 test하다가 자주 이런 일이 발생할 것같기도 해서...
내친김에 run-time debugging feature를 만들어버렸다.

static __inline__ int mz_debug_on_p(void) {
return (mz_ops.stat & MZ_DEBUG_ON);
}

echo 1 > /proc/sys/debug/enable 이면 debugging-on
0이면 off하게...
가볍게 생각하고 다음과 같이 code를 고치고 룰루랄라했는데...

if (test_and_set_bit (1, &rtc_status))
+#ifdef CONFIG_MIZI
+ if (!mz_debug_on_p())
+#endif
return -EBUSY;
rtc_irq_data = 0;

이런... 한번 debugging feature를 on 시켜서 강제로 열면 계속 열리는 것이 아닌가!!! 헐헐헐... 가볍게 끝날 것같던 code가 결국 5시간이나 debugging을 해야했다. (중간에 점심시간을 생각해도 T.T)

close()쪽에서 rtc_status를 clear하는 것을 미쳐 생각 못한 것.
더하기 변수 하나 (open된 횟수 세는 놈) 추가하기 싫어서 rtc_status의 상위 16bit가지고 끄적거린다고 버린 시간이 5시간 된 것이다. --;;;

결국 변수하나 추가하고 (처음부터 그럴 것이지...) 해결봤다.

open()...
#ifdef CONFIG_MIZI
if (mz_debug_on_p()) {
rtc_open_cnt++;
if (!test_and_set_bit (1, &rtc_status))
rtc_irq_data = 0;
return 0;
}
#endif
if (test_and_set_bit (1, &rtc_status))
return -EBUSY;
#ifdef CONFIG_MIZI
rtc_open_cnt++;
#endif
rtc_irq_data = 0;
return 0;

close()...
#ifdef CONFIG_MIZI
rtc_open_cnt--;
if (mz_debug_on_p()) {
if (rtc_open_cnt > 0)
return 0;
}
#endif
spin_lock_irq (&rtc_lock);
RTSR = 0;
blah... blah...