| 1. | 2 Sep 2000 - 19 Sep 2000 | (376 posts) | 마이크로소프트의 GPL 위반 가능성; Kernel Debugger in Official Sources |
| 2. | 7 Sep 2000 - 19 Sep 2000 | (64 posts) | Wine In The Kernel; GPL Loopholes |
| 3. | 13 Sep 2000 - 23 Sep 2000 | (44 posts) | PowerPC 포트 관리에 관한 불확실 |
| 4. | 14 Sep 2000 - 15 Sep 2000 | (31 posts) | 추가적 커널 디버거 주창 |
| 5. | 16 Sep 2000 - 23 Sep 2000 | (54 posts) | 모듈과 In-Kernel(커널 내재) Driver의 차이를 없애는 것 |
| 6. | 17 Sep 2000 - 19 Sep 2000 | (13 posts) | VM에서 예약페이지(Reserve page)를 사용가능하게 유지하기 |
| 7. | 17 Sep 2000 - 20 Sep 2000 | (13 posts) | PERCRAID 3 드라이버 오픈소스가 되다. |
| 8. | 17 Sep 2000 - 22 Sep 2000 | (61 posts) | Getting Very Close To 2.4.0 |
| 9. | 19 Sep 2000 | (4 posts) | Deadlock Hiding In New VM |
| 10. | 20 Sep 2000 - 22 Sep 2000 | (14 posts) | linux-kernel Digest Discontinued |
| 11. | 21 Sep 2000 - 22 Sep 2000 | (22 posts) | New VM May Not Make It Into 2.4 |
| 12. | 22 Sep 2000 - 24 Sep 2000 | (12 posts) | es1371 Sound Card Catches Bad Fixes |
지난 주 Kernel Traffic #86, Section #16 (16 Sep 2000: "NFS Patches In 2.2; Yes, 2.2") 에서 unexpanded <kcref> (inter-issue reference)를 고친 것에 대해 Chris Beckenbach, Michael Cope, Jeff Gage에게 감사한다. 부가적으로 Jeff는 Kernel Traffic #86, Section #9 (12 Sep 2000: "Using Netware Elevator Ideas In Linux")에서 에서 < 와 >사이의 문장을 삭제할 수 있게 했다. 잡기 힘든 버그를 잘 잡아 주었다. 감사!
Thanks also go to Peter Samuelson for catching me inadvertantly sticking extra text into a quote by Alan Cox in Kernel Traffic #86, Section #8 (12 Sep 2000: "Backporting The IDE Patch"). I've fixed it so that at the bottom of that section, Alan no longer seems to direct people to a different KT section ;-). Thanks, Peter!
Mailing List Stats For This Week
We looked at 1594 posts in 5945K.
There were 402 different contributors. 203 (50%) posted more than once. 161 (40%) posted last week too.
The top posters of the week were:
토론 중에, Jeff V. Merkey는 왜 어떤 코드는 공개할 수 없는지 설명했다. "만약 우리가 이걸 포스트하면, 마이크로소프트사가 가로채서 그들이 우리사이트에서 다운로드한지 48시간 만에 NT의 코드가 될 것이다." Andre Hedrick는 답변했다. "마이크로소프트에 관해 무슨 뜻인지 안다. 나와 동료들의 리눅스에서 taskfile을 다루는 완전한 코드가 리눅스에서는 첨가되지 못했지만 마이크로스프트의 휘슬러2001에 사용되고 있다. 그들은 리눅스의 가장 좋은 부분을 자신의 것으로 만들고 있다." Henning P. Schmiedehausen은 GPL 위반에 대해서 FSF에게 가볼 걸 제안했지만, Andre는 패치가 커널에서 거절당하면, 더 이상 GPL의 관건이 아니고, MS는 그것을 마음대로 할 수 있다고 답변했다. 그러나, Theodore Y. Ts'o는 지적하기를, "그건 말도 안된다. GPL은 판권소유다; 이건 코드가 커널이든 아니든 상관없다. MS(또는 누구든) 허락 없이 당신의 코드를 쓸 수 없다. GPL은 어떤 약간의 제한으로 허가를 주는 것이다." Andrew McNabb 이 다르게 말하기를 "당신이 만 든 코드에 대해서 암묵적인 판권을 소유하게 된다. 당신이 쓰는 코드에 허가를 구분하느냐에 관계없이, 코드를 훔치는 것은 불법이다. GNU라이센스는 당신의 조건에 동의할 경우 코드를 사용하도록 한다." In response to Ted, 어떤 사람은 아무도 MS에 대항, 고소해서 돈을 받으려고 하지 못할 것이라고 했다. 허나, Henning은 다음과 같이 말했다. "FSF는 분명히 대항할 것이다(that's what RMS dreamed all about since he started GNU. :-))." [...] "나는 FSF가 일을 벌리면 많은 지지자가 금전적인 도움을 줄 것이라고 확신한다."
다른 주제로, Jeff는 커널 디버거가 없다는 것을 불평했다. Jes Sorensen는 'kdb'가 계속 있어왔다고 하지만, Jeff는 다음과 같이 말했다.
kdb 여전히 형편없다. Double fault를 디버그 할 수 있는가? No. IF ((EAX == 1) &&[ESP-4] == 0x3000)와 같은 복잡한 레지스터와 연산 을 디버그 할 수 있는가? NO. SMP의 lock race를 디버그하는가? NO. Sleep lock에서 priority inversion 문제를 디버그하는가? NO.
커널디버그가 Netware에서 작동할 수 있나? YES. 커널디버그가 NT에서 작동할 수 있나? Yes.
Alan Cox는 대답했다:
Remote gdb on Linux - yes. 소스코드 레벨의 디버그는 할 수 있다. 불행하게도 Linus만이 상당한 수준의 디버그를 커널에 넣는 것을 혼자 반대하고 있는 것 같다.
도구들은 존재하고 그 도구들이 x86에 또한 sparc 와 그 외 maintainer가 있는 기반의 컴퓨터에도 포트되어야 한다.
Jeff는 말하기를, "이유는 단지 컨트롤 일뿐이고, 그 외의 어떤 유효한 기술적 이유는 없다. 나는 printk()에 많은 시간을 썼다." 그리고 David S. Miller는 답변하기를:
그리고, printk와 씨름하면서 배운 교훈과 문제는 결코 잊혀지지 않을 것이고, 이후에 같은 종류의 문제를 당했을 때, 정확하게 어디를 봐아야 할 것인지 알게될 것이다.
디버거는 이런 역할을 할 수 없다. 디버거는 당신을 게으르게 만들고, Null이나 확인하고, 뭐하는지 _생각_도 안 하게 만든다.
이게 바로 Linus가 이런 도구를 커널에 허용하지 않아서 디버그를 할 때 _생각_ 하는데 시간을 쓰게 하는 것이다.
이런 식으로 버그를 잡는데 시간이 더 걸리지만, 결과적 수정은 더 우수하다. 또한 버그를 발견한 사람에게 커널의 원리에 대한 많은 지식을 준다.
Alan은 답변했다. "There are only a few things I think Linus is a complete loon about 8) but the debugging stuff is one." David는 동의하지 않고 다음과 같이 말했다. "내가 산 것보다 더 많은 기간 디버그를 한 2명의 해커(Kernighan과 Pike)가 나와 동 의한다는 것이 힘이 된다. 그들의 책, "The Practice of Programming"의 제 5장을 읽어보라. 특히 119쪽 둘째 단락을 주의해서 보라."
다른 곳에서, Ingo Molnar가 커널 디버깅에 대해서 한 마디 했다:
두 종류의 'debugging behaviors'가 있다:
A) 'local context를 이해하기 위해 충분한 데이터를 얻은 후에 버그를 고친다.'
B) '직접 크래쉬(crash) 되는 곳을 찾아서, 그 코드에 대해서 생각하고, 그 코드를 부른 코드를 생각하고, 그 코드의 의도와 수행을 생각하고 그 코드를 이해하는 것으로부터 버그를 찾는다.'
A) 보통 쉽거나 어지간한 커널의 버그를 잡는 사람들이다. 이런 사람 들은 디버거에 나타난 버그 주위의 시스템 상태에 분명히 나타나지 않 으면 어떻게 할 줄을 모른다.
B)소스코드에 기초해서 버그를 밝혀내는 능력이 있는 사람들이고 어 리둥절할 정도로 잡기 어려운 버그를 고치는 능력이 있는 사람들이다. 2.3 커널에서 한 10개정도의 이런 버그가 있었다. 나는 진짜 주요 커널 개발의 병목은 이런 어려운 버그를 고치는 일이라 고 주장한다. 이런 어려운 버그들이 개발 커널에 새 기능을 첨가하게 한다. 그러므로 우리는 사람들에게 적절한 디버그 방법을 가르치기 위 해 모든 일을 해야한다.
A) 는 쉬운 버그에서는 시간이 적게 걸린다 - 드라이버 개발을 빠르게 할지도 모른다. 그러나, 진짜 어려운 문제에서는 무용지물이다. 2.3 에서 우리는 최강의 디버그 장치도 찾을 수 없는 버그들이 몇 개 있었다. 디버깅 코드는 코드의 의도를 흐트려서 B)를 어렵게 만든다.
B) 는 배우기에도 실제 쓰기에도 느린 일이지만, 그렇지만 더 많은 코드 향상(버그랑 관련 없는 코드도)하게 하고 더 좋은 커널 개발이 된다.
문제는 개발자의 게으름이다. ;-) 우리가 경험이 있는 사람들이 쉬 운/어지간한 버그를 빠르게 고치게 하기 위해 디버그 코드를 포함할 수 도 있다. 하지만 문제는 디버그 도구가 지금처럼 '간소화' 되지 않았다면, 사람들이 코드를 이해할 필요가 없어진다.
나는 IKD/KDB와 같은 독립된 디버그 기능에 반대하지 않는다.(사실 은 공헌도 했다.) 커널 개발과 맞게 최신으로 할 수는 없지만, 개발 커널은 전술적 목적이 아닌, 전략적 목적에 맞추어야 한다.
Andi Kleen은 유용한 디버그 도구를 제하는 것이 Ingo의 "A"방법을 더 적 게 쓰게 한다고 생각하지 않았다. Ingo는 답하기를, "사람들은 커널의 개발과 원리와 코드를 이해하는 것이 쉽게 버그를 고 치는 것이라는 것을 금방 알것이다. 이 처럼, 우리는 커널 디버거나 작동할 줄 아는 100명의 일반적 개발자보다 차라리 커널을 이해하는 숙련된 10명의 필요하다. [이건 경험은 적은 자에게의 모독이 아니다 - 경험이 없다는 것은 그저 임시적인 단계다. 그러나 그대로 끝나면 큰 문제지만 IMHO.]" Richard Gooch는 답변하기를, "I think there's a certain amount of wishful thinking . 모든 사람들이 아무것도 없는데서 시작한다. 그런데, 학습/개발 적응도가 너무 느리거나, 진행이 너무 좌절하기 쉬워서 많은 부분의 잠재적 gurus를 놓칠 수도 있다. 당신은 사람들이 가길 원치 않는 길로 그들을 밀어넣을 수는 없다." Ingo는 누구든 'kdb'와 다른 디버깅 패치를 사용할 자유가 있다라고 답했다.
이 쓰레드 이 지점에서 Linus Torvalds가 나서서 그의 의견을 진술했다.
난 디버거가 싫다. 한번도 좋아해 본적이 없고, 좋아하지 않을 것이다. 나는 gdb를 사용하는데, 디버거로는 사용하지 않고, disassembler로 사용한다.
지금까지 어떤 토론도 나를 조금이라도 감동시키지 못했다. 나를 믿어라. 수년간 많은 디버거에 관해 들었지만, in the end, they tend to boil down to basically:
- 개발하기 쉬워지고, 새 기능을 빠르게 첨가할 수 있을 것이라는 것이다.
솔직히 상관안한다. 커널 개발이 "쉬워서는" 않된다. 나는 버그를 찾기 위해 코드를 한 칸씩 찾아다니는 것을 불쌍히 여기지 않는다. 나는 시스템을 추가적으로 더 볼 수 있다는 것이 좋은 것이라고는 생각하지 않는다.
분명히, 토론을 따르면, 커널 디버거가 없는 것이 다음 같은 악재가 되게 한다고 한다.
- 뭔가 잘못될 때, 시스템은 크래쉬되고, fsck하면 끝도 없이 시간걸려서 결 국 포기한다.
- 사람들이 리눅스 커널 프로그래밍이 너무 어려워서 시간이 너무 걸려서 포기한다.
- 새 기능을 만드는데 오래 걸린다.
하지만 누구도 왜 이런 것들이 _나쁜_ 것인지는 설명하지 않는다.
나에게는, 이건 버그가 아니고, 기능이다. 이건 문서화 되었을 뿐 아니라 _좋은_ 것이기도 하다. 그러므로 버그가 아니다.
"새 기능을 만드는데 시간이 오래 걸린다" - 특히 이는 디버거를 만들자 는데에 대한 이유가 될 수 없다. 리눅스, 또는 모든 소프트웨어 업계에게 기능이 없다거나 새 코드가 부족하다는 것은 문제가 안 된다. 반대로, 나 의 중요한 역할 중의 하나는 새 기능을 거절하고 새 기능을 찾으려 하지 않는 것이다.
물론 무엇인가가 잘못되어 fsck해도 무엇이 잘못인지 모를 때, 절 망하게 된다. 그럴 때 두 가지 반응이 나온다: 하나는 조심스 럽게 생각하거나, 다른 하나는 커널 디버거가 필요하다고 짜증을 내는것이다. 솔직히, 조심스럽지 않는 사람들을 일찌감치 상대하고 싶지 않다. 너무 냉정하게 들리는가? it _is_ callous. 그렇다. 냉정한 일이다. 하지만 결코, "부엌이 너무 덥다면 밖으로 나가자"와 같이 사람들이 당연히 받아들이는 그런 일은 아니다. 이는 좀 더 심오한 것이다. 나는 차라리 조심스럽지 않은 사람들과 일을 하지 않겠다. 이는 소프트웨어 개발의 적자생존이다.
냉혹하고 경직한 논쟁이다. 하지만 두 번째 종류의 사람들하고는 일하고 싶지 않다. 그렇게 살겠다.
나는 개자식(번역자 왈: 진짜 이렇게 써있습니다) 같은 놈이다. 나는 왜 사람들이 다르게 생각할 수 없는지 모르겠다. 내가 좋은 시스템을 위해서는 다른 사람들이 많은 시간을 들여 한 작업이나 다른 사람들의 마음의 상처도 무시한다. 사람들은 내가 좋은 사람이라고 잘못 생각한다.
그냥 말로만 하는게 아니다. 나는 정말 좋은 사람이 아니다. 내가 "i don't care(신경껐 다)" 라고 얘기하면 정말로 그런 것이다.
나는 커널 디버거가 없다는 것이 사람들을 디버거와 다른 레벨에서 문제 에 대해서 생각하게 만든다고 믿는다. 디버거를 가지고는 어떻게 작 동하는지 원리에 대해서 생각해 볼 필요없이 문제를 고치려하지만. 디버 거가 없으면, 문제를 다른 방법으로 생각하게 된다. 문제를 다른 _레벨_ 에서 생각해야 한다.
이건 조금은 "source vs binary" 이지만, 그 이상이다. 꼭 소스를 봐야 한다는 것은 아니다. (물론 보아야한다 - 좋은 디버거는 그것을 _쉽게_ 만들 것이다) 소스 _이상_의 레벨을 보아야 한다는 것이다. 단지 코드 한 줄이 아니라.디버거 없이 다음 단계로 가야하고, 프로그램이 무엇을 하는지 이해해야 한다.
그리고 솔직히, 대부분의 실제적 문제가(바보 같은 버그가 아니고- 예를 들면, 요즈음의 "trucate()") 디버거에서는 별 도움이 안된다. 내가 걱정 하는 것은 실제적 문제들이다. 그 나머지는 세부사항일뿐이다. 이런 것들은 최종에는 해결된다.
다른 사람들이 동의하지 않는 것을 안다. 내가 당신들 엄마는 아니지 않는가. 당신들이 원하면 커널디버거를 사용하라. 당신들이 자신을 "모독"했다고 내 가 당신들을 학대하지는 않을 거다. 그러나 나는 디버거 사용하게 도와주지는 않을 것이고, 그만큼 사람들이 디버거를 사용하지를 원치않는다. 그러므로 디버그를 표준배포의 일부로 만들지 않고, 존재하는 디버거가 알려지지 않았 다고 해서 안타까워하지도 않을것이다.
나는 개자식이고, 이것이 자랑스럽다.
이에 대한 많은 응답이 있었고 모두들 강하게 찬/반하면서, (subthreads)하위쓰레드들이 가지쳤다.
David Howells는 공고했다:
나는 wine의 속도향상을 위해서 커널모듈에 win32 "system call"을 수행하였다.
내가 만든 예비 벤치마크(실제-세상의 벤치마크 만큼은 아직 안되지만) 로 어떤 시험에서는 syscall latency가 win2000보다 20% 낫고 wine보다 200% 낫다.
Wine은 동기화와 <->fd 맵핑을 다루기 위해 추가 프로세스(wineserver)를 사용하고, 컴뮤니케이트를 위해 sendmsg와 recvmsg가 사용되 기 때문에 이렇게 느린것이다.
내가 적은 코드에 대해 한마디 해주면 바란다.(이 문서 아래 붙어 있음) 나는 또한 다른 사용자공간 메커니즘이나 커널공간을 조금 덜 침입 하는 방식으로 얼마나 많은 속도 향상이 있는지도 대해서도 궁금하다.
또한 사용자 공간에서 커널공간으로 옮기는 더 좋은 방법을 찾는데 관 심이 있다... 현재, 이건 proc 파일을 여는 것과 win32 작업 요청 에 ioctl을 하는 클라이언트 프로세스가 관련있다. (커널 모듈에서 하기 쉽다.)
그러나, ioctl syscall은 몇 개의 표준 I/O 명령에서 많은 (속도)벌점을 일으키는 것 같다.
언급했었던 다른 방법에는 Linus를 설득해서 이런 목적의 특별한 syscall번호를 떼어 놓고 모듈을 이것의 핸들러(handler)로 삼자는 것이다.
Martin Dalecki이 강하게 반대했다:
절대로 이 패치를 공식 가지에 포함하지 말라. 다음과 같은 이유로 이것은 미친짓이다:
- Linux는 Unix지 NT가 아니다... (API에 관한 한)
- Wine은 거의 쓸모없다 - 사실 어쩜 존재하지 않을지도 모른다. 공식적으로 안정된 릴리즈(release) 조차도 없기 때문이다.
Adam Sampson은 동의했지만, 다음과 같이 냉철하게 덧붙혀서 말했다. "나도 이 패치가 공식트리에 포함되서는 안된다고 생각한다. 하지만 나의 경우는 이것이 너무 가깝게 wine의 사용자공간 라이브러리에 연관되어 있기 때문이다; 이건 대신 wine의 일부분이 되어야한다. (이것이 ALSA와 lm_sensor와 같은 다른 패키지들이 관리되는 방법임을 주목하라)" Adam과 (다른 사람들도) wine이 유용 했다는 것에 반대했고, and shouldn't be put down just for being pre -1.0
Albert D. Cahalan는 David의 생각에 반대하지 않고 말하기를, "만약 당신이 일반 윈도우 벤치마크를 작동할 수 있을 정도로 실현하면, 참 재미있을 수도 있다." 다른 곳에서는, David의 처음 제안에 대해, Linus가 대답하기를:
NT syscall을 그냥 직접 수행하면 훨씬 좋을 것이라는 생각이 든다.
iBCS2라는 프로젝트가 있었고, 이것이 순수 Linux 프로그램이 iBCS2프로그램보다 많아지면서 중요하지 않은 관건이 되면서 나는 사실 이것을 표준 커널의 일부를 만들 생각이 있었다.
그리고 우리는 이미 오랫동안 vm86 모드와 DOSEMU용 BIOS trap 속도 향상을 보아왔다.
만약 우리가 이걸 하려면, 즉시 실시해서 vm86 모드 이뮬레이트처럼 "우리가 확실히 알고 성능도 확실한 것" 을 해야한다.
나는 Wine을 지원하는 것에 반대하지는 않겠다 - 어느 정도 깨 끗하게 (커널에서) 분리되어 있는 한. 그렇게 나쁘게 보이지는 않는다.
논쟁 중에 다이나믹하게 할당하는 syscall entry의 가능성이 제기되면서 다음과 같은 technical discussion이 있었다. Linus가 다음과 같이 나설 때까지 찬반이 있었다. Linus가 말하기를:
문제는 dynamic system call은 발생하지 않는다는 것이다.
왜?
이는 사용허가(License) 문제이다. 나는 system call이 모듈로부터 첨가되는 것을 허락하지 않을 것이다. 나는 module을 위해서 system call을 첨가하는 것은 적적하지 않다고 생각하기 때문이다. 간단하다.
이건 "hook"에 관한 오래된 일이다. Hook를 가지고 GPL을 슬쩍 스쳐가려 해서는 안 된다. 그리고 dynamic system call은 궁극적인 hook이다.
Pavel Machek이 지적하기를, "당신들은 _GPL-ed_ 모듈에 dynamic system call이 첨가되는 것을 막을 순 없다."
KT는 Kernel Traffic #8, Section #13 (27 Feb 1999: "Possible GPL Violation By Mosix")에서 이런 종류의 loophole의 가능성에 대해서 다루었다. Richard Stallman도 여기서 한 마디 했다.
Dwayne Grant McConnell가 Linus에게(다른 여러 사람하고 몇 개 리스트에 있는 사람들에게도) 말하기를, "Cort Dougan이 최근 PowerPC Linux 계열을 관리하지 않겠다고 공 고했다. IBM 안에는 32비트와 64비트 하드웨어용 PowerPC Linux를 위해서 열심히 일하는 팀이 있고 우리의 PowerPC 리눅스 개발에 관 심은 끊이지 않을 것이다. 우리는 Paul Mackerras와 그 외 다른 이 들과 Power PC Linux와 그 방향에 대해서 현재의 안건에 대해서 같 이 일해 왔다. 우리는 PowerPC Linux 계열의 발표를 위해서 준 비해 왔고 몇일 후 발표 할 것이다. 우리가 AS/400, RS/6000의 PowerPC Linux을 관리하겠다는 내용을 Maintainers 파일에 포함해 주겠는가?" 그는 자신과 Tom Gall을 Maintainer 리스트에 추가하기 위해 패치를 포함했다. 그러나 Paul Mackerras는 대답하기를 "내 생각에는 Cort는 더 이상 http://www.ppc.linux.org/를 관리하고 있지 않다고 한 것 같다. PowerPC용 리눅스를 관리할 수 없다는 것은 아닌 것 같다. Cort는 잠시 휴가 중이다." Dan Malek도 같은 인상을 받았고 응답하기를:
나는 화요일 Cort와 몇 시간쯤 만났다. 난 Cort가 뉴멕시코에서 오 늘(수요일)쯤 돌아올거라 생각했고 지금 혼란을 일으킨 메시지에 관 해 대답할 수 있기를 바랬다.
우리는 커널 소스 트리를 어떻게 잘 관리할 수 있을지 토론했고, 내 생각엔, 그는 분명히 일할 의도가 있었다. 우리들처럼 Cort도 다른 직업이 있고 어떨 때는 우리가 원하는 만큼 빨리 응답할 수는 없다.
그러던 중, Cort Dougan도 Paul에게 응답했다. "내가 말하려했던 것은 내가 하는 진짜 직업을 위해서 잠시 PPC에서 휴가를 보내려고 했던 것이다. PPC를 버리려는 것은 아니고 잠시 동안 여기에 시간을 좀 덜 쓰려고 했던 것이다."
이 토론은 여기서 다른 얘기로 바뀐다.
Keith Owens는 다음과 같이 제안했다:
이 노트는 커널 디버거를 마스터 tarball에 포함할 경우에 대한 것이 다. 이것은 kdb만이 아니라 다른 Kernel debugger에도 포함된다. Kdb, kgdb, xmon의 이미 알려진 단점에 대한 얘기는 여기서 전혀 상 관없고, 언제 어떻게 디버거를 작용시킬 것인가도 상관없다. 나는 *어 떤* 표준 디버거가 있어야하는가에 대해 집중하고 싶다.
만약 Linus가 계속 마스터 tarball에 어떤 디버거든 포함하는 것에 대해서 "안돼"라고 하면 내가 생각하기에는 이 쓰레드는 여기서 끝이다. 그럼 나 는 배포자들에게 그들의 패치에 디버거를 포함하는 것에 대해 말할 것이다. 바라건데, 배포판 배포자들이 표준 디버거에 동의하기를 원한다.
공개: 나의 일중의 하나는 kdb를 관리하는 것이다. SGI는 GPL 협조로부터 이익을 얻기 위해 kdb가 많이 사용되기를 원한다. 더 많은 관심과 작업은 모든 사람에게 더 좋은 코드를 의미한다.
자~ Linus 이제는 어떤가? 이것이 당신의 표준 커널 디버거에 관한 마음을 바꾸지는 않았는가?
- Random kernel error들은 문서화나 디버거로 보고하기가 쉽다. "아차 실수였다"로만 문제를 찾기는 항상 충분하지 않고 어떤 때 는 변수와 control block을 볼 필요가 있다. 특히 하드웨어 문제는 더욱 그렇다.
- 상업환경에서 리눅스 지원은 표준 커널디버거에서 득을 얻을 것이다. 우리가 결국 원하는 것은 각 상업 지원자들이 다른 디 버거를 포함하는 것과 다른 (bug reports)버그 보고를 제공하는 것이다. 지원 되는 시스템의 버그 보고는 지원자들에게 보내져야 하지만 일부는 main linux list에서 거를 것이다.
- 아키텍처 간의 일관성. Sparc, mips, mips64, ppc, m68k, superh, s390은 이미 그들의 표준 커널에 원격 디버거 지원을 한다. I386, alpha, sparc64, arm, ia64는 표준 디버거가 없어서, 추가적 패치를 해야 한다. 어떤 아키텍처는 원격 gdb 이외에 추가적 디버거 코드도 갖는다.
- 디버거의 일관성. 1997년에 많은 각자의 커널 디버깅 패치가 새는 메모리(memory leaks), stack overflow, lockup 등을 위해서 사용되고 있었다. 이 런 패치들은 다른 패치들간에 충돌이 있어서 사용하기 힘들었다. 나는 여러 개의 다른 디버그 패치를 쓰는 것보다 하나의 표준 디 버그 패치를 가지는 것이 모두를 위해 쉬워서 Integrated Kernel Debugging(IKD) 패치를 만들었다. 커널 디버거도 마찬가지다. 모 든 커널들이 사용하는 하나의 디버거를 만드는 것이 커널 코드를 지원하는 모든 사람의 생산성을 향상시킬 것이다. 왜냐면 여러 개의 다른 디버거의 의미를 배워야할 필요가 있기 때문이다.
커널 초보자들이 커널 내부를 배우기가 쉽다. 수년간 10개 이상의 운영체제에서 일한 경험에서, 나는 어떤 모양의 Kernel/OS 추적 장치는 사람들이 공부를 시작하는데 상당한 도움을 준다고 증언할 수 있다. Linus가 다음과 같은 얘기했고 이에 동의한다. Linus가 말하기 를
"'룩크(스타워즈의), 소스를 사용해라. 소스를 사용해라. 코드와 하나가 되어라.' Luke Skywalker가 deathstar에 다아가 갈 때 자동 발사 장치를 꺼버리고 양성자 torpedo를 수동으로 발사한 것을 생 각해보시오. _그러면_ 당신은 커널 버그를 고칠 마음의 준비가 된 것이다."
하지만 Linus는 또 말하기를 "주된 술수는 그런 짜증나는 '아차' 하는 메시지들이 5년의 경험을 가진다는 것이다. ;-)" 초보자는 그런 경력을 가지는 어떤 방법이 필요하다. 맨 처음부터 소스코드 를 읽는 것은 무시무시할만큼 배우기 힘든 일인데, 디버거는 소스가 하는 일을 보여준다. 항상 커널 사용자의 90%이상이 초보자라 는 것을 기억하고 이런 커널 초보자를 커널 전문가로 바꾸는 것은 좋은 일이다.
대부분의 경우, 커널디버거가 더 나은 패치가 된다는 것에 반대한다. Linus가 말하는 것처럼 사람들이 디버거를 잘못 사용할 때 가 많다. Linus가 말하기를
"나는 많은 사람들이 디버거의 출력을 보고나서 버그를 고칠 때가 많고, 그것이 내면의 문제 보다는 증상을 고치는 것임을 피할 수 없다는 것이 두렵다."
정말이다. 나는 수년간 이런 착오를 하고 있다. 피할 수 없는것인가? 아니다. 12개 아키텍처중 7개의 표준 커널에 이미 디버거가 장치되어 있다. 이 아키텍처들이 디버거가 있기 때문에 더 나쁘다는 증거가 어디 있는가?
누군가가 문제보다는 증세를 고치기 위한 패치를 내놓더라도, 그것도 좋은 정보이다. 증세를 고치는 것은 집중을 불러일으키고 그와 관련된 정보가 진짜 문제를 고치도록 돕는다. 우리는 디버거가 없어도 문제가 있는 패치들을 쓰게 되지만(최근의 truncate 문제는 얘기하지 말자 ;) 많은 사람들이 커널에 관심을 갖고 문제의 패치를 찾아서 제거 하려한다. 표준 디버거를 첨가하는 것은 이런 패치에 관심을 갖 는 사람들의 수준을 빠른 속도로 향상시킬 것이다.
Jeff V. Merkey와 David P Howell는 기꺼이 찬성했고; Richard Moore는 다 음과 같은 말을 덧붙혔다.
내 생각에는 커널 디버거에 관한 경우는 커널의 RAS(Reliability, Serviceability, Availability)에 관한 경우에 더 잘 설명이 된다. 다시 말해서 적절한 시간, 적절한 곳에서 적절한 분석을, 보고를, 회복도구 를 써야 할 때가 있다. Kdb는 분석에서 RAS의 필요를 충족하지 못한다. 매우 강력한 개발도구이지만, but hang on so is a logic analyser and source-level debugger. 논리분석기와 소스레벨 디버거도 마찬가지이다. Kdb는 어샘블러에 기초한 디버거를 사용해서 HLL소스를 디버그 하려면 더 더욱 사용하기가 불편하다. 요점은, 대체적으로 프로그래머가 다루는 semantics와 어울리는 디버거가 필요하다는 것이다. 만약 어샘블러코드이면 그냥 kdb를 쓰라. 만약 h/w에 특정한 인터페이 스와 시스템버스에 관한 것이면 낮은 레벨의 도구가 필요할 것이다.
그러면 kdb가 시험판/상업용/기업용 환경에서도 모두 표준 커널의 부 분이 되어야 할까? 난 그렇게 생각하지 않는다. 수년간 상업환경에서 사용된 기술을 보면 OS/2만이 kdb를 사용하는 사치를 했다. 우리가 지원한 OS의 반정도엔 kdb가 없었다. OS/2는 흥미있는 경우 였다. 왜냐하면, 처음 OS/2는 디버그의 목적으로 kdb를 사용했었고 우리가 지원했던 플랫폼 중 serviceability는 최악이었다. 우리 는 생산환경에서나 실험실에서 쉽게 다시 재현할 수 없는 그런 전형 적 특이한 문제들은 디버그 할 수 없었다. 우리의 형편없는 serviceability때문에 고객들은 엄청난 양의 고생을 했다. 여러번 문제를 디버그 하지도 않았다. 물론 우리도 열심히 해 보려고는 했다. 고객들은 우리가 OS/390(그때는 MVS라고 불렀다)를 디버그하기 위해 개발자를 한 번도 보낸 일이 없다는 것을 알았다. 또한 고객들은 우리가 문제들을 다시 실현을 할 수 없기 때문에 문제 를 거절하지 않았다는 것도 안다. 그 이유는 MVS에서 fault time에 어느 정도의 자동 회복기능과 함께 그 때의 데이터를 포착하는 적절 한 RAS 기능이 있었기 때문이다. 우리가 OS/2를 이 정도 수준의 RAS 기능으로 만들기 위해 한 일은 system dump 기능을 만드는 것 이다 - SGI의 kernel crash dump와 비슷한 것 + 코드 재컴파일 없이 다이나믹하게 조정할 수 있는 완전한 시스템 추적 장치, IBM의 리눅스용 dynamic probe가 이 기능의 첫 포트(port)이다. + 완전 하고 사용자가 조정할 수 있는 가상메모리에 기초한 dump.
이런 기능들이 약간의 어려움으로도 우리의 심각한 난해한 문제를 디 버그하는 능력을 바꾸어 놓았다. 우리가 이것들을 해놓고 나서 즉시 성공을 거두었다는 것은 사실이다. Interactive 디버그에 비해서 포착된 데이터를 가지고 일하는 데는 배우는 시간과 생각을 바꿔야 하는 점이 있기는 하다.
Kdb를 버리지는 않았다. 아직까지 매우 유용하다:
- 교훈적인 도구
- 문제결정의 최종 단계를 위해서 - 모든 문제는 무엇이 이 문제를 일으키는지를 알면 다시 재실행할 수 있다. Dump와 trace를 얻을 수 있는 경우이면, 마지막 미스터리를 풀기 위한 디버거를 사용한 랩에서의 실험을 할 수 있다.
- 매우 드믄 경우의 생산 중에 하위의 하드웨어들이 무엇을 하는지 알아야 할 경우에는 논리 분석기(logic analyzer)를 사용하는 것이 경제적인 방법의 하나이다.
어떤 종류의 RAS에 대항한 논쟁 중 하나는 이것이 커널을 부풀리며 어느 누구도 그런걸 원하지 않는다는 것이다. 리눅스와 관련한 더 많은 논란은 아마 RAS를 병존하게 하려면 상당한 양의 수고를 해야 한다는 것이다. 우리가 지금 하고 있는 일이 도움이 될 수도 있 고, 다음의 Dynamic Probe가 Generalized Kernel Hooks Interface(GKHI)이면 도움이 될 것이다. 요점은 모든 RAS 기능을 다 이나믹하게 load할 수 있는 커널 모듈로 만드는 방법이다. 많은 경 우 커널의 기능을 바꿀 필요는 없고, 적당한 시간에 컨트롤 하면 된다. Hook를 커널소스에 놓아서 RAS 모듈이 요청을 해서 할성화 될 때까지 잠을 자게한다. 아마 이런 방법으로 어려움을 해결 할 수 있을 것이다.
Timur Tabi도 Keith의 제안에 동의하고 Keith의 5번째 요점에 가장 관심을 보였다: 디버거를 사용함으로 인해 초보자들은 커널 해킹을 쉽게 배울 수 있다. Timur는 말하기를, "나는 Linus가 내가 커널을 어려운 방법으로 배우려하지 않는다고 가치없는 사람처럼 치부했을 때, 그에 대한 존경심을 잃었다." 그에 대해서 Marco Colombo가 대답하기를:
그래서 linus가 맞는 것이다. 그의 주된 주장은 사람들의 선택이다. 어려운 방법으로 하지 않으려는 사람들을 몰아내는 것이다. 당신은 그저 그의 전략이 성공을 거두고 있다고 말하고 있을 뿐이다.
한가지 묻겠다: 만약 당신이 커널이 어떻게 작동하는지 배우려하고 디버 거가 필요하면, 자기 스스로 패치를 하는 것이 어떠한가? Linus가 자기 의 tree에다 하는 일은 당신이랑 상관이 없다. 나는 공부(learning)하는데 있어서 리누스에 대해 왈가왈부해서는 안된다고 생각한다.
Linus의 주된 포인트는 '어려운 방법으로 하라' 혹은 '하지 마라'가 아니라고 생각된다. 포인트는 "디버거를 가지고 하는 것이 쉬운 방법 은 아니다"라는 것이다. 이 방법이 쉬워 보이지만 지식을 얻을 수 없다는 것이다. 결국은 이건 '올바른 법'과 '그른 법'이지 '어려운 법'과 '쉬운 법'이 아니다. 이 점에서 나는 Linus에 동의한다. 나 는 소스코드는 생각을 표현하는 언어이다(또한 언어이어야 한다)라는 것을 첨가하고 싶다. 잘 쓰여지 소스는, '어떻게 작동하는가'를 이해 하기 위한 디버거가 필요 없다. 그리고 필요하다고 생각되어진다면, 처음부터 소스에 문제가 있는 것이다. 소스코드는 디버거의 출력보 다도 사람이, *특히* 초보자가 읽기 쉬워야 한다. 이런 점에서 Linus 는 잘하고 있다.
내가 Linus에 반대하는 부분은:
- 사람들이 하고 싶은 일을 할 수 있는 자유를 주어야 한다는 것이다. 사람들이 디버거와 시간을 보내려고 하면 그렇게 하게 해야한다. 그의 'social engineering'은 말도 안된다. 사람을 거른다고 더 괜찮은 사람을 만드는 것이 아니다.
- 사람들이 생산하는 (patches, features) 패치나 기능과 같은 것에 엄격한 관리를 해야지 어떻게 생산품을 만들었는지는 관여하지 말아야 한다. 만약 Linus가 맞다면 (그리고 맞는다고 믿는다), '디버거 사람들'은 (증상을 고치고 문제는 해결하지 못하는) 낮은 품질의 패치를 만들 것이고 이런 패치들을 Linus가 좋아할리가 없을 것이다. Alan이 진짜 문제를 찾으려 하는 사람들에게 어떨 땐 도움이 될 수 있다고 말한것은 맞는 말이다.
Frederic Magniette는 커널디버거가 사람들이 나쁜 패치를 만들게 할 수 있 다는데에는 동의했으나, 특히 커널이 segment faulting하기 시작하면, 자신의 커널코드를 디버그 하는 일은 매우 어려운 일이라고 말했다. 그는 주장 하기를, "이런 일이 벌어진 후에는 수많은 변수를 인쇄하고 뭘 해야하는지에 대해서 궁리하는 긴 작업을 시작해야 한다. 만약 코드가 많이 불려지면 (called) 로그가 퇴색된다. 이런 식으로, 내 생각 으로는 커널디버거는 패치 도구 뿐만이 아니라 강력한 코딩 도구도 된다."
더 많은 토론이 있었는데 한 시점에서 Keith가 말하기를, "많은 사람들이 나의 노트, "The case for a standard kernel debugger" 에 관해 응답을 해서 이것이 좋은 생각인지에 대해서 토론했다. 허나 오직 한 사람, Linus의 응답만 중요하다. 나는 다른 사람들에게 Linus가 이 토론 thread를 읽어서 대답할 때까지(읽을지 모르지만) 기다려 달라고 부탁했다." Jeff가 대답하기를, "나는 Linus가 Keith의 메시지를 읽었다고 생각한다. -- 그는 어떤 커널 디버거에 관한 내용도 거절할 것이라고 했다. :-)"
Jan Niehusmann은 test9-pre1이 드라이버가 직접 커널로 컴파일 되었을 때 (모듈로 된 것의 반대 의미로) SCSI 디스크가 두 번 감지되는 문제를 고치지 못했다고 보고했다. Torben Mathiasen, 이 문제를 고치는 패치의 개발 자는 #ifdef MODULE을 첨가하고 결과적으로 2.5의 SCSI 하위시스템을 분 해수리하는 것을 제안했다. 그러나 Linus가 대답하기를:
왜 커널 안으로 컴파일 되었을 때는 두 번 하고, 모듈로 했을 때는 한 번만 하는지 설명해주시오. 분명히 추가 초기화를 하는 다른 이유 가 있을 것이고 차라리 그것을 제거하는 것이 좋을 것이다.
나는 모듈이 In-kernel과 다르게 작동하는 것이 싫다. 당신은 지 금 나를 보고 두개를 더 다르게 만들어서 결과만 똑같게 만들자고 하 는데, 왜 두개가 같은 logic으로 작동하게 할 수 없는지 알았 으면 한다.
기본적으로, 분명히 어딘가에 다음과 같은 역할을 하는 것이 있다.
if (!module) init_subsystems();
왜 이 부분을 제거해서 두 개를(모듈과 in-kernel)을 똑같이 작동하 게 할 수 없는지 모르겠다.
Jan과 Torben은 몇몇 포스트된 메시지를 찾아 보았고, Torben은 다음과 같이 말했다. "적절하게 작동하는 것 같은 패치를 첨부 했다. 문제는 호스트 감지 유닛이 스커지 드라이버(sd/st/sr)의 상위층 초기화를 하려하고, module_init이 또 다시 이것을 하려는 것이다. 이것을 없앴고, 모든 디바이스 초기화는 module_init에서 된다." Linus가 대답하기를, "좋다. 코드를 정리 해달라." [...] "내가 원하던 패치이다. 감사하다." Linus 자신이 코드를 살펴본 후 다음과 같이 얘기했다:
이것은 SCSI 층이 모듈에 의존한 또 한 경우이다. 이것이 모듈이면, scsi/scsi.c의 "init_module()"을 사용하고, 아니면, 대신 "scsi_dev_init()"을 사용한다. 둘은 비슷한 일을 하지만, 왜 그런지 모르지만 방법이 다르다.
Torben, 이전의 패치를 확장하고 이 부분을 정리하겠는가? 내 가 보기에는 scsi_dev_init()을 완전히 제거하고 모듈 init 코드를 initcall()과 같이 사용해야 할 것 같다. Two less regions of #ifdef MODULE, and one less different code-path to worry about..
Why was this done this way anyway? I've never seen this kind of setup in any of the other drivers that have been de-liced of module dependencies...
Jeff Garzik과 Eric Youngdale은 이것은 코드의 역사에 의한 것이라고 했다. Eric이 말하기를, "SCSI는 모듈 기술이 매우 원시적일 때 모듈화 되었다. 시간이 갈수록 두개의 초기화 방법이 합쳐지고 지금은 서로 중복된 것이 되었다." Torben은 패치를 만들기 시작했고 곧 예비 버전을 볼 수 있을 것이라고 했다. 이때 Linus가 한 번 더 생각하고 말하기를, "잠시 기다시오." 하고 설명 하기를, "MODULE의 경우가 모든 걸 해결하는 것 같다. 나는 지금 #ifdef MODULE이 삭제된 커널을 작동 중이고, 쉬운 방법 인 것 같다. 몇몇 부분을 static으로 바꾸고(안 그러면 init 루틴이 충돌 한다) 많은 #ifdef MODULE을 삭제했다. (그리고 in-kernel에서만 작동하는 부분을 제거했다) 매우 직관적이다."
Eric이 확인하려고 묻기를, "여기서 주된 목적이 무엇인가? - #ifdef MODULE을 제거하는 것인가? 두개 중에서 중복되는 부분을 제거하는 것인가? 아니면 둘 다인가?" Linus는 "둘 다이다."라고 대답하고 다음과 같이 정리했다.
알고 있듯이, 모든 것은 몇 년 전에 생긴 미련한 버그(모듈의 init과 커 널의 init 둘 다 작동하기 시작하는 것 때문)를 고치기 위해 시작되었다. The fact that it wasn't clear which happened where is really for me the driving force here - i'd like to avoid the same bug cropping up in half a year when somebody cleans up some low-level driver init.
그리고 host.c의 init 리스트를 제거하는 것은 보너스로 왔다. Module init path를 보면 이 리스트는 자동으로 없어진다.
Linus가 test9-pre3를 내놓았고 많은 사람들이 변화를 살펴보고 기술적인 점에 대해서 토론했다.
Patrick Mau는 /proc/sys/vm/freepages가 더 이상 2.4.0-test9-pre1에서 쓰기허가가 없다고 보고했다. 의도적인 것이냐고 물었고, Dave Jones는 새 VM에서 "이 항목을 바꾸는 것은 더 이상 재구성된 코드에 관계가 없다."고 말했다. Rik van Riel은 더 자세하게 Patrick에게 대답했다:
의도적인 것이다. 이 파일에 쓰는 것은 2.3.50 쯤에서부터, zoned VM에 합쳐지면서, 작동하지 않았다.
그리고, 새 VM이 직접 재요구할 수 있는 비활성 페이지들의 리스트 를 유지한다는 것은 이 값을 가지고 논다는 것을 더 이상 필요없게 한다.
Andi Kleen은 기가비트 네트워크와 같은 인터럽트가 심한 작동에서는 VM이 많은 페이지를 유지하게 하는 방법이 있어야 한다고 했다. Rik이 그렇게 못하는 기술적 설명을 했고, Andi는 "그럼 이건 load burst를 할 수 없다. 기본값으로는 괜찮은데, 특별한 load에서는 전의 freepage와 같은 관리자가 쓸 수 있는 기능이 있으면 좋겠다." 고 했다. Rik은 "좋소. 리눅스 국회에서 좋은 아이디어(self-tuning)가 있는지 알아봅시다. ;)"고 대답했다. Andi는 이 경우에 VM 코드가 적응하기 전에 많은 packet을 놓칠 것이므로 self-tuning을 좋아하지 않았다. 그가 말하기를, "만약 관리자가 "10mb가 낭비되어도 상관없다. 이런 식으로 원한다" 라고 말하면 그렇게 하게 할 수 밖에 없다."고 했다. Rik 도 동의했고 이 기능을 더하겠다고 했다. 또 Andi는 다음과 같이 말했다. "만약 다시 freepage를 통해서 할 수 있다면 좋을것이다. 그럼 문서를 다시 쓸 필요도 없다. 지금 어떤 번호들이 (예를 들면 middle number) 의미가 없지만 VM의 목적으로 사용될 수 있다."
Bruce A. Locke는 2.2.14용 바이너리 커널 모듈과 함께 있을때만 작동하는 것 같은 Dell사의 PERCRAID 3 카드를 가지고 있다. 그는 다음과 같이 질문했다. "Dell의 기술지원 웹 사이트는 위에서 말한 바이너리 모듈만 나타난다. 누가 PERCRAID 3 카드 에 대해 알거나 오픈소스 드라이버가 있는 사람이 있는가? 아니면 최소한 새 커널에서도 작동하는 바이너리 모듈이라도?" 두개의 하위thread가 가지쳤다. 첫번째, Wakko Warner는 "내가 아는 한, Dell사가 이 드라이버를 썼고, 소스를 공개하려고 하지 않는다." 라고 했다. Alan Cox는 "PERCRAID용 드라이버 는 adaptec의 판권소유가 있고 결국 사용이 허가되었지만 현재는 매우 불안 정하고 spinlock에서 down()을 사용하는 것과 같은 징그러운 버그의 잠재성 이 많다. Adaptec 사람들이 정리하는 중이다."라고 했다. 그리고 후에 덧붙이기를, "똑 같은 버그가 다른 binary driver 에도 있을 것이 분명하다. 이렇게 작동하는 것이 신기하다."
다른 토론 thread에서 Bruce에게 응답하면서 Dell의 Matt Domsch는 말했다.
"PERCRAID 드라이버는 Alan Cox에게 제출됐는데,
드라이버에 안에 너무 많은 "NTism's"를 내포하고 있어 거절되었다. 소스
코드는 Red Hat Linux의 "Pinstripe" 베타 커널 소스 RPM이나 나에게 직접
연락해서 구하길 바란다." Jon Mitchell은 소스가 Dell의 사이트에 있
다고 했고, Bruce는 다음과 같이 말했다 "레드햇
The accard driver patches 레드햇의 pinstripe 커널 SRPM이 2.2.17에서
작동한다. 상당히 안정적이고 속도도 binary driver와 비슷한 것 같다.
이 thread에서 Igmar Palsenberg는 "내 의견
으로는 생산자들은 다시 써야 하는 버그가 많은 소프트웨어를 만드는
것보다도 문서를 제공해야 한다."라고 했다. Alan은 그들이 다시 소프트웨어를 쓰고 있으니까 나는 상관치 않는다.
그리고 한번 드라이버를 읽으면 어떻게 코드가 작동하는지 알기 쉽다.
그들은 SCSI에 관한 것은 감추려고 하지 않지만 filesystem(aacraid
는 카드 자체의 file system을 한다)은 감춘다."
고 했다.
Linus Torvalds는 2.4.0-test9-pre2을 공고하고 말하기를, "알려진 버그가 없는 상태로 다가가고 있다. 다시 말해서, 2.4.0-test9를 마지막으로 심각한 문제(Ted의 목록에 있는)가 없는 한 다른 패치를 받아들이지 않을 것이다." Alan Cox은 대답하기를, "음.. 그럼 나는 드라이버를 2.2에서 2.4로 수정할 시간이 없을 것 같은데, 무지하게 많은 것을 고쳐야 할 것 같다." 그리고 Rik van Riel도 Linus에게, "음.. 새 VM이 메모리 부족(out of memory) 방지가 아직 준비가 안됐는데.. 빨리 out of memory/low on swap에 관한 작업을 해서 패치를 보내겠다. 리눅스 국회(Linux Kongress)에서 얼마나 잘 연결 될 것이냐에 따라서..."
Russell King은 여러 포팅 관리자에 관해서 물었고, 오늘 늦게까지 (소 스)tree로 변화시킨 것을 올려 놓을 수 있는지도 물었다. Tom Rini도 좋은 질문이라고 하고, 다음과 같이 정리했다. "PPC는 아직 해결해야 할 문제가 좀 있다(이러면 안되는데, 거의 모든 새 컴퓨터에서 무수한 PCI resource collision이 발생한다.) 분명히 다른 아키텍처도 그들의 -dev list에는 나와 있겠지만, l-k(linux kernel)에 포스트 되지 않은 문제들이 있을 것이다." Martin Schwidefsky는 덧붙이기를, "나는 몇 주전부터 s/390 아키텍처의 업데이트를 하고 싶었는데 좀 더 중요한 일이 있었다. 틈틈이 시간을 내서 linux-2.4.0-test8에 붙일 패치를 만들었다. Arch/s390, include/asm-s390과 drivers/s390에 사용될 diff 파일은 1MB로 상당히 크다. S/390에 아닌 것에 사용될 diff 파일은 그저 35KB. 문제는 패치를 지금 원하십니까, 아니면 2.4.1까지 기다릴까요?이다."
이쯤에서 몇몇 사람들이 2.4가 너무 오래 기다리게 한다고 불평했고, Cort Dougan은 다음처럼 말했다:
내 생각에는 2.4는 버그수정은 비교적 적고 불필요하게 잘 작동하는 코드를 다시 써서 오히려 불안정하게 하고 안정적인 2.4를 늦어지게 하는 것 같다. 씁쓸한 일이다...
나는 PPC용 2.5를 시작했다. 2.4랑 보조를 맞추어서 공식적 2.5가 나 올 때 별 어려움 없이 바꿀 수 있을 것이다. 나는 지금 2.4로만 버그 수정을 허락하고 있다.
만약 2.5 tree로 액세스하고 싶으면 기꺼이 외부에 공개하겠다.
David S. Miller 대답하기를:
2.4.x를 아직 시작하지 않은 _이유는_ 사람들이 새 기술을 가지고 일하 는 것보다는 2.4.x를 더 안정적으로 만드는데에 집중하게 하기 위해서이다. 사람들에게 물어보라. "아직 2.4가 준비도 안됐는데, 왜 experimental stuff을 가지고 일하는지, 왜 PPC stress test나 하고, kernel regression suite을 적용하는지"
만약 당신이 사람들이 2.4에서 일하지 않는것을 독려하고 있다면 2.4.x 가 늦는다고 불평을 해서는 안된다.
Cort 대답하기를:
나의 PPC 친구들은 바꾸고 싶은 게 있다. 그들은 막을 수는 없지만 안정적이어야 하는 2.4를 작살내는 것은 막을 수 있다. 만약 그들이 2.4의 버그를 고치고 싶지 않으면 내가 어떻게 할 도리가 없다. 그들이 나를 위해서 일하는 것은 아니고 나도 PPC에 관여한 사람들을 위 해서 일하는 것이 아니다. 그러므로 나는 그들이 하고 싶지 않은 일을 하 라고 심하게 강요하지 않을 것이다. 나는 그들이 PPC용 2.4를 불안 정하게 만드는 것은 효과적으로 막고 있었다. 내 생각에는 잘한 일인 것 같다.
그리고 그들의 실험(experimental stuff)이 안정적을 될 때까지 실험 을 할 공간도 주었다. 일단 안정이 되면 2.4로 옮기고 그렇지 않 으면 2.5를 기다리겠다.
David은 그런 접근방식에 동의하지 않았고 토론은 한동안 계속되었다.
Anton Petrusevich는 새 VM 코드에 메모리가 적은 시스템에서 deadlock이 발생한다고 보고했다. Rik van Riel에게 얘기했지만 Rik은 문제를 찾을 수 없었다. 사람들에게 자신의 시스템에서 완벽하게 시험해 보라고 했다. "mem=8m에서는 init 스크립트도 재대로 할 수 없다." Mike Galbraith는 메모리가 많은 (128M)의 시스템 에서도 비슷한 문제가 발견된다고 보고했고 Rik는 Anton에게 말하기를:
나는 나의(SMP, SCSI)시험 시스템에서 mem=8m으로 부트해서 아무 문제가 없길래 이 문제를 고쳤다고 생각했다.
IRC의 누군가는 이것이 UP-only bug일 수 있다고 제안했다. 내가 이 문제를 확인해서 고쳐 보겠지만, 도움을 받을 수 있으면 좋겠다.
(나는 아직 Linux Kongress에 있고 한동안 사무실로 돌아오지 않을 것이다.) Rik이나 그 외의 사람들과 IRC에 얘기하고 싶은 사람은 #kernelnewbies at irc.debian.org를 확인하시오.
공식 소스로 VM 패치를 Linus가 받아들이는 것에 관한 내용은 Kernel Traffic #86, Section #15 (15 Sep 2000: "New VM Goes In 2.4: The Saga Heats Up")를 확인 하시오.
Robert Greimel은 Linux-kernel digest가 다시 시작할 수 있냐고 물었고 (리눅스 커널을 vger.Rutgers.edu에서 vger.kernel.org로 옮기면서 사라짐) Matti Aarnio는 David S. Miller가 안된다고 했다고 말했다. Matti는 "어떤 때 David은 나쁠 가능성 있는 의견은 매우 냉혹하게 대한다, 하지만 다른 면에서 Majordomo 1.x digester는 MIME 메시지의 구조를 깬다. 쉽게 고치겠지만, 나는 Zmailer는 해킹하는데 Md는 하지 않는다." Dmitry Pogosyan은 어리둥절해서 물었다. "linux-kernel-digest는 많은 관심있는 사람들에게 리눅스의 개발에 대해 알려주는 좋은 방법이었는데 이건 매우 불행한 일이 다. 이것이 없어지므로, 하루 > 200개 이상의 커널과 관련한 메일이 활동적이지는 못한 개발자에게 도달할 수가 없다." Matti는 'procmail'로 사용하자고 제안했다.
다른 곳에서 Alan Cox는, "mailman으로 바꾸는 것이 majordomo를 작동하는 것보다 헐씬 덜 고통스러울 것이다."라고 했다. David은 "나도 그러고는 싶은데 Matti는 mailman은 해결해야 할 RFC compliancy 문제가 있다고 한다." Alan은 좀더 이 문제에 관해 들어보고 싶다고 했고, Matti는 대답하기 를:
일 이년 전에 Zmailer과는 작동이 되지 않는다는 보고가 있어서 알아 보니 SMTP를 위한 PYTHON의 라이브러리에 protocol line construction에 잘못된 부분이 있었다. 문제가 있었던 시스템은 매우 엄격한 RFC 821(수정추가)모드와 작동하는 Zmailer를 작동하는 시스 템들이었다.
MAILMAN이 괜찮을 수도 있다, 하지만 그 아래에는 버그가 있는 라이브러리가 (아직도) 있을 수 있다.
다른 문제점은, MAILMAN이 Python으로 쓰여 있는데, 우리 중 누구 도 Python을 할 수 있는 사람이 없다…
Oliver Xymoron은 "Python은 상당히 읽기 쉽다. Perl과 C를 아는 사람에게 이미 써있는 코드를 해킹하는 것은 그리 어렵지 않을 것이다."라고 했다. 아무도 대답을 안 했는데, 다른데서 Steven Pritchard가 말하기를:
현재 Majordomo 2가 개발 중이다. 나는 이것으로 나의 리스트들에게 사용한다. Majordomo 1에서 업그레이드로 그리 힘들지 않았다.
이것은 거의 새 버전이 아니고, 완전 다시 만든 것 같다. MIME, archives, digests, 그리고 다른 것도 다 원하는 것처럼 잘 작동한다. 허나, 아직 공식적, 안정적 배포는 아직 없다는 것이 걸린다.
지금 보기에는 전의 digest를 보기 원하는 사람들은 majordomo의 업그레이 드나 다른 소프트웨어로 바꿀 때를 기다려야 할 것 같다.
Rik van Riel 공고하기를:
새 VM의 deadlock을 고쳤다. 문제는 단일cpu에서만 발생한다. 그래서 나의 SMP 시스템에서는 crash 되지 않았던 것이다. ;)
이 문제는 프로세스가 kswapd를 깨운 후에 IO lock을 유지한 상태로 스케쥴에서 없어진다는 것이였다. 그 시점에 kswapd는 IO lock을 돌면서 시간을 쓰게 된고 단일 cpu 시스템은 죽게 된다.
접속상태가 안 좋아서 이 패치를 같이 보내지는 않았지만, 나의 홈페이 지에 올려 놓았다:
http://www.surriel.com/patches/2.4.0-t9p2-vmpatch
(지금 회의중이다... 이 패치를 가지고 가장 어려웠던 것은 mem=8m을 'make bzImage'를 하는라고 꼬박 밤을 샌 것이다.)
많은 사람들이 똑 같은 또는 더 안 좋은 deadlock에 대해 보고했고, Linus는 다음과 같이 경고했다. "이런 문제들을 빨리 고치지 않으면, 그 VM 패치들은 빨리 제거해 버릴 것이다. 매우 실망했고 deadlock으로 가득찬 당신의 새 코드보다 차라리 옛 VM에 page aging을 첨가해서 쓰는 것이 쉬울것이다." Rik이 대답하기를:
지난 주에 회의에 가 있어서, 코드를 커널에 집적한 후에 코드를 살 펴볼 시간이 없었다. ;(
UP-only deadlock과 page ping-pong을 발견해서 고치고 있는 중이다.
가능하다면, 다음 주에 코드를 집적(intergate)했으면 하는데... 회의 중에 하는 것은 정말 어렵다. ;)
나는 지금 email backlog과 버그 보고를 보고있는 중이다.(오늘, 화 요일, 수요일은 /다른/ 회의에 갈 것이고, 목요일 기회가 있다)
내가 보기에는 근본적인 문제는 없는 것 같고, 몇 주내에 고칠 수 있 는 여러 개의 작은 문제들이 있는 것 같다.
이 메시지가 교환되기 이전에, Rik은 'if' 문에서 어쩔 수 없이 논리를 바꾸어야 하는 곳을 찾았다. Ingo Molnar는 즉시 시험한 후 패치와 함께 답장을 했다. "그렇다. 여기에 속임수가 있었다. Deadlock은 이제 없어졌다. Vanilla test9-pre5에 적용할 완전한 VM 수정 패치를 같이 보낸다." Rik은 Linus에게 Ingo의 패치를 다음 pre-release에 포함하라고 요구했으나, Andr Dahlqvist와 Yuri Pudgorodsky가 이 패치에 흠이 있다고 보고했다. 답장은 없었고, 이 thread는 여기서 끝났다.
다른 곳, 의 제목으로, Linus는 2.4.0-test9-pre6를 배포하고 말 했다. "이것이 VM deadlock(knock wood) 를 고칠 것이다."
누군가 esl371 사운드카드가 2.4.0-test9-pre5에서 작동을 중지한다고 보고 했다. 가장 마지막으로 이 카드를 작동했던 test7에서는 문제없이 작동 했다. Mordechai Ovits는 어떤 카드들은 test8에서 잘 작동했었다고 말 했다. Linus는 코드를 본 후에 엉터리 버그수정을 구했다. Linus가 버그수정 을 만들었고, Jon Evans는 Linus의 bugfix가 성공적이라고 보고했고, Linus 는, "내가 그 엉터리 패치를 보낸 사람을 찾아서 혼쭐을 내줘야 겠다. 물론 이런 것을 받은 내가 바보지만." Alan Cox는 2.2.18pre를 수정을 했었다고 대답했다. "이건 2.2에서 2.4로 빠져나간 버그이지, 버전을 높이는 포트한 사 람의 잘못은 아니다." Jeff Garzik은, "내가 그 패치를 만든 사람이다. 그렇지만 이건 직접 2.2.x에서 나왔다. 양쪽 버전의 ac97_codec과 그밖의 것들을 확인해 보겠다."라고 했고, Linus는, "이것이 2.2.x에서는 작동했다는 것이 놀랍다. 이건 2.4.x가 2.2.x와 완전히 다르게 작동한다는 것을 의미한다."
We Hope You Enjoy 커널 트래픽
|
All Kernel Traffic and Cousin issues and summaries are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0. |