FreeBSD 8.0 Code Freeze

2009년 6월 26일자로 Ken Smith 씨가 8.0 HEAD 소스에 대한 code freeze를 실시하였습니다.  그 전날까지 엄청나게 커밋 메일들이 오더군요. 

제 기억이 맞다면 이번 릴리즈에서는 7.0 릴리즈에서의 실수를 되풀이하지 않기 위해 PR로 등록된 이슈가 아닌 커밋에 대해서는 core팀에서 가급적 허락을 하지 않을거라 합니다.  7.0 릴리즈 때 code freeze 후 몇 달이 지나도록 릴리즈하지 못했던 이유가 OS 의 중요 파트에 대한 커밋 approval 로 인해 계속된 리뷰 및 이슈로 인한 것으로 압니다.

저 같은 경우는 제가 할 수 있는 일들은 대부분 이전에 해둔 상태였기 때문에 큰 걱정은 없었지만 마지막에 NDIS USB support에 대한 이슈가 올라오면서 버그 fix를 간신히 커밋하였습니다.  하지만 제가 나름대로 maintain 하는 드라이버들에 대해 안정성이라던가 구현의 완벽성이 다른 타 드라이버들에 비해 떨어지는 것 같아 항상 부끄럽게 생각합니다.  (원체~ 초절정 고수들이 많은 곳이라 항상 배우는 자세로 임하고 있습니다. ^^)

미국으로의 이사 문제와 곧 다가올 결혼식 준비로 인해 주말이 되어도 시간이 없어 코드들을 돌보지 못해 안타깝습니다.

upgt(4) 와 urtw(4) 포팅 완료

그 동안 작업 중이던 upgt(4) 와 urtw(4) 가 USB2용으로 모두 포팅되었습니다.  이로써 제가 책임지고 있는 드라이버에 대한 작업은 모두 다 한 듯 한데 8.0 릴리즈를 대비하여 (기존 계획대로라면) 6월 1일에 예정되어 있는 Code Slush 전에 하게 되어 조금은 마음이 놓입니다.

앞으로 약 2 ~ 3 개월 동안 릴리즈 준비가 되면서 발견되는 버그에 대해 MFC (Merge From Current) 할 일만 저에게 남아 있을 뿐입니다.  물론 항상 쌓여 있는 PR 과 함께요.  이제 좀 더 안정화 부분과 구현이 미흡했던 부분을 수정을 해야 할 듯 합니다.

▶◀ 노무현 전 대통령 서거

old USB 에서 HPS USB stack 으로..

FreeBSD 8.0 릴리즈를 위한 Code Freeze 가 6월 중순으로 발표되면서 요즘은 회사일 하랴, FreeBSD 포팅하랴 정신이 없을 정도로 한가하지가 않습니다.

이와 관련하여 저에게 닥친 가장 큰 이슈는 역시나 Hans Peter Selasky (일명 hps) 아저씨가 만든 hps USB stack 인데 , 그 동안 만든 드라이버가 USB 와 많은 부분을 공유하다 보니 이런 일이 발생하였네요.

8.0 릴리즈에서 가장 큰 변화중의 하나를 들라면 아마도 USB stack 의 변화가 아닐까 합니다.  그 동안 USB 드라이버들이 모두 Giant Lock 에 둘러싸여져서 돌아갔었는데, hps stack의 경우 Giant free 이기 때문입니다. (좀 더 fine-grained locking 을 SMP 머신입장에서 제공하게 될 듯 합니다.)  하지만 사용자 입장에서는 잘 모르겠지만 드라이버를 개발하는 저에게는 이 변화의 장점보다 단점이 많이 보여서 나름 정리해 보겠습니다.

• USB KPI가 모두 변해 버렸습니다.  이건 사용자 입장에서도 치명타이고 개발자 입장에서도 마찬가지입니다.  왜냐하면 그 동안 짜놓았던 프로그램을 다시 다 맟춰야 하니까요.  이로 인해 현재 old USB 에서 지원되던 upgt(4), urtw(4) 가 현재 CURRENT 에는 없습니다.  Porting 부터 다시 해야 합니다.  이걸 왜 해야 하는지도 이해를 못하겠습니다만..
• USB 공부를 다시 해야 합니다.  낯선 KPI 및 xfer 구조체의 변화, PIPE 개념의 제거, xfer callback의 변화 등등 기존 USB1을 이용하여 개발하던 사람들은 처음부터 다시 시작하는 마음으로 공부를 해야 합니다.  이건 좌절이었습니다.
• 자세한 문서를 찾을 수가 없습니다.  최고의 방법은 hps 아저씨에게 직접 물어보는 겁니다…
• old USB에서 잘 작동하는 것들이 hps USB에서는 동작하지 않는 경우가 있습니다.  (물론 이 문제는 앞으로 조금씩 해결되어 갈 것이니 걱정하지는 않습니다.)

이 외에도 개발하면서 만나게 되는 문제는 여러가지가 있습니다만 좀 더 지켜볼 필요가 있을 듯 합니다.  저에게 좋은 소식 한가지는 Andrew Thompson 아저씨가 USB data buffer 구조를 기존 old USB stack 과 거의 흡사하게 변경하도록 계획하고 있다는 겁니다.  저는 100% 찬성이거든요.

오늘 저와 Sam Leffler 아저씨가 같이 만든 uath(4) 을 hps USB stack 용으로 commit 을 완료하였습니다.  (아직 build 에 연결하는 것과, amd64 나 big-endian 머신에서의 테스트를 더 해야 하지만..)  이제 upgt(4) 와 urtw(4) 를 porting 해야 합니다.

여전히 할 일이 많고 시간은 촉박합니다…. :-p

Total Phase - Beagle USB 480 Protocol Analyzer

드디어 저에게도 USB Protocol 분석기가 생겼습니다. (생긴지는 2 주 이상 지났지만..)  그 동안 대부분의 작업을 USB 와 관련된 부분들을 하다 보니 몇몇 개발자분들이 FreeBSD Foundation 에 정식으로 분석기를 신청해 봄이 어떻겠냐는 말씀들을 해주셔서 신청 grant 을 보낸 적이 있었는데, 2008 년도에 fonding 받은 것이 잘 되었는지 저에게까지 기회가 온 것 같습니다.   승인이 된 것입니다!

제가 구입한 것은 Total Phase 사에서 나온 분석기이며, 가격은 $1200 (원화 현재 시세로는 165 만원 정도) .  제가 현재는 직장인이지만 개인 돈을 들여 살만큼 풍족하지는 않기 때문에 저에게 이 장치를 제공해 준 FreeBSD Foundation 에 정말 감사드립니다.

하지만….. ㅠ.ㅠ 통과 관세가 31만원을 개인돈을 내야 했으니… 절대 잊지 않겠다.  관세청…

분석기의 경우 16 ns 주기로 bus 상에서의 패킷을 챕처 하기 때문에 대부분의 패킷을 모두 dump 할 수 있을 것으로 예상되는데, 아마 이 분석기는 아래의 용도로 사용될 것 같습니다.

1. 물론 FreeBSD 의 USB stack 과 USB 드라이버 (대부분 wireless 와 관련이 있을 듯..) 의 개발에 사용될 것입니다.  USB stack 의 경우 비록 현재 HPS USB stack (일명 newusb) 가 활발하게 작업중에 있지만 거기에 제가 개발을 할 것 같지 않습니다.
2. 버그 해결에 사용될 수 있을 것입니다.  USB 드라이버를 작성하면서 난관 중에 하나는 내가 내린 명령이 실제 하드웨어로 전달이 되었는지 혹은 올바르게 전달되었는지를 확인하는 과정인 것 같습니다.  또한 target 에서 host 로 제대로 응답을 보내주는지 확인 하는 것두요.  Timing 과 관련된 USB 이슈들도 수도 없이 많을 수 있습니다.  분석기를 사용하여 정말 BUS 내에서 어떤 일들이 있을지 확인할 수 있기 때문에 하드웨어와 관련된 버그 해결은 정말 쉬워지는 것입니다.
3. 디버깅 혹은 reverse engineering 에 사용될 수 있을 것입니다.  NDIS 드라이버에서 전달되는 패킷을 덤프한다거나 여러 가지에서 사용될 수 있을 듯 합니다.

이제 이 분석기를 이용해서 만든 모든 코드 들에는 의무적으로

• Sponsored by: FreeBSD Foundation

을 붙여야 될 것입니다. :-)  기분좋은 일입니다.

urtw(4): HEAD에 commit됨

몇 주 (최소 1주?)된 소식이지만 그 동안 urtw(4)가 HEAD에 commit되었습니다.  urtw(4) 는 Realtek 8187L chipset을 지원하는 wireless USB 드라이버로써 제가 최초로 만든(지금까지는 다른 BSD에 있는 드라이버를 FreeBSD 용으로 porting 하거나, 다른 src committer 가 일부 작성한 것을 제가 이어 받아 나머지를 작성한 형태였음) 드라이버입니다.

현재 urtw(4)는 처음 perforce 에 등록 된 후, Kevin Lo 아저씨에 의해 OpenBSD로, Michael Li 아저씨에 의해 OpenSolaris로 porting이 성공적으로 되었습니다.  Datasheet없이 작업한 드라이버라 여러 곳에서 한계가 명확한 것 같은데, 예를 들면

• RX/TX 의 전송 속도가 떨어집니다.  현재 7 ~ 8 Mbps 정도입니다.   Linux 코드의 경우, 이에 대한 rate control 알고리즘(PID 혹은 minstrel 등등)이 FreeBSD 의 것과 달라 이를 적용해야 할지 확신이 서지 않았습니다.  현재는 RX 패킷내부에 들어 있는 rate 정보를 기반으로 TX시 사용하고 있는데 완전하지 않습니다.  이에 대한 수정이 필요합니다.
• AP mode, ADHOC mode, TX fragmentation, TX power management, H/W encryption 등등의 기능이 빠져 있습니다.

Realtek 칩셋의 경우는 다른 제조사보다 wireless 사용자가 있는 듯 한데, 드라이버 제작 후 8187B 칩셋과 8187SE 칩셋에 대한 지원도 해달라는 문의가 많습니다.  8187B 칩셋의 경우는 구조가 8187L 칩셋과 거의 비슷해서 어렵지 않게 지원될 수 있을 듯 한데 (쇼핑물에서 8187B 칩셋을 가지고 있는 제품도 구했습니다.), 8187SE 의 경우 Mini PCI-express 형태라 지원이 어려울 듯 합니다.  제가 아래 중 한 개도 가지고 있지 않기 때문입니다. 

1. Mini PCI-express slot을 가지고 있는 노트북
2. 테스트용으로 사용할 PCI-express slot을 가진 데스크탑 (이전에 JMicron 에서 어렵게 구한 Mini PCI-express -> PCI-express converter 을 가지고 있습니다. :-)  엄청난(!) 도움을 주신 편X헌님(my boss)에게 무한 감사 드립니다.

기부 받습니다. 

urtw(4) 먼저? uath(4) 먼저?

어제 Sam Leffler 아저씨가 uath(4) 을 HEAD에 넣는게 어떻겠냐고 물어보셔서 p4 나 HEAD 둘 중 아무거나 상관없다고 했었는데 우선 p4 에서 좀 더 많은 review 을 거칠 것 같습니다.

오후에 uath(4)을 정식으로 p4에 commit을 하고 나니 머리가 조금 어지럽네요.  urtw(4)는 어느 정도 코드 모양새가 갖추어져서 HEAD에 들어가도 될 듯 한데 uath(4)와 동시에 할려고 하니 머리가 multitasking이 안됩니다.  (참고로 urtw(4)는 OpenBSD에는 이미 Kevin Lo 아저씨가 작업을 해주셔서 HEAD에 들어가 있습니다.)

uath(4)의 경우는 아직 HEAD로 들어갈려면 좀 더 많은 수정을 해야 할 듯 합니다.  간단히 부족한 점을 열거한다면

• Multicast 패킷에 대한 처리를 하지 못해 IFF_ALLMULTI 로 처리하고 있으니 안타깝습니다.  AR5523 processor에는 multicast filter을 위한 spec이 정의되어 있습니다만 processor 와 driver 사이에 HAL 이 있어서 HAL 인터페이스를 쓸 수 밖에 없는데 이를 어떻게 사용해야 하는지에 대한 문서가 전무하네요.  오족했으면 NDIS 드라이버도 IFF_ALLMULTI 로 세팅 (물론 윈도우즈만의 방식으로) 하겠습니까…
• 하드웨어 crypto 가속기를 지원하지 않는점.  HAL에서 지원하는 h/w accelerator 를 쓰지 못해 좀 더 완벽한 드라이버가 되지 못하고 있습니다.
• AD-Hoc 모드 지원이 안되는 점.  이에 대한 코드는 반드시 작성되어야 할 요소입니다.  제 실력이 미천하여 아직은 답보 상태로 있습니다.  IEEE802.11 스펙에 기술되어 있는 기능들을 지원하려면 좀 더 많은 수정이 필요할 듯 합니다.
• AP 모드의 경우 현재 HAL 자체가 지원하지 않기 때문에 앞으로도 지원여부는 불투명할 듯 합니다.  (갑자기 든 생각이지만 upgt(4)의 경우 리눅스 wireless-testing GIT 트리에 AP 모드를 지원하고 있는 듯 한데 upgt(4) 을 업데이트해서 AP 모드 코딩을 해 보고 싶네요.)

여튼 urtw(4) 을 헤더에 먼저 집어 넣을 건지 아니면 uath(4) 을 먼저 테스트를 더 많이 할 것인지 헷갈리네요. ㅋ  고민입니다.  그래도 조만간 이 두개의 드라이버를 HEAD에서 보실 수 있을 것입니다.

FreeBSD 7.1 릴리즈

정말 생각보다 오래 걸렸습니다.  svnadmin/conf/approvers 기록을 보니까 4개월 전에 Code Freeze가 되었었네요.  이 날짜가 맞는지는 정확하게 모르겠습니다만 제 느낌은 그냥 오래 걸린 듯 합니다.

근데 7.1 Release Notes 를 보고 있는데 malo(4) 에 대한 언급이 빠져 있네요.  Hiroki Sato 씨에게 말을 해봐야 할 듯 합니다.

자세한 내용은 아래 링크를 참조해 주세요.

• http://lists.freebsd.org/pipermail/freebsd-announce/2009-January/001229.html

malo(4) 드라이버는 제가 FreeBSD에서 활동하며 올린 두번째 wireless 드라이버인 것 같습니다.  벌써 소스의 마지막 커밋 날짜가 8개월이나 지난 걸 보면 세월이… (malo(4) 드라이버 사용자는 가뭄에 콩나듯 보입니다. ㅋ  제가 만든 혹은 포팅한 드라이버 중 가능 안정적인 녀석입니다만..)

stable/7 로 MFC 하지 않은 것들이 몇 개 있는데 이제 좀 더 편하게 할 수 있을 듯 합니다.

나의 첫번째 build break

오늘 오후 5시쯤에 NDIS USB support 관련 code 들을 commit을 하였습니다.  오후 7시30분까지 컴퓨터 앞에 있으면서 world(make buildworld)가 깨질까봐 계속 메일을 주시하고 있었는데, 아뿔사 결국엔 저의 첫번째 build break 을 기록해 버렸네요.

newusb (이하 USB2) 코드에도 ndis 관련 부분이 있는데, 현재 NDIS USB 는 original USB (이하 USB1) 코드 기반으로 되어 있어 생긴 문제였습니다.  USB2 모듈 빌드에서 ndis 부분을 제외시켜버림으로써 일단 문제는 수습해 놓은 상태입니다.

역시 major commit 을 할 때는 최소한 buildkernel은 꼭 해보고 commit을 해야 할 듯 합니다. 현재 상황은

• 8시46분에 amd64 가 깨짐
• 9시 18분에 i386 깨짐
• 10시 32분에 i386/pc98 깨짐
• 11시 39분에 ia64 깨짐

음…  근데 i386/pc98 이랑 ia64의 경우 NDIS 지원이 되지 않는 platform임에도 불구하고 build을 시도하는 것은 USB2 모듈 Makefile에 문제가 있나 보군요.  수정되어야 할 부분으로 보입니다.  참고로 현재 NDIS 코드는 amd64랑, i386만 지원됩니다.

앞으로 몇 시간 동안은 계속 tinderbox 가 계속 불평을 할 듯 합니다..  의외로 신경이 많이 쓰입니다.

NDIS USB 지원 for FreeBSD

휴…  거의 7 개월 정도 작업했던 결과물을 FreeBSD 소스 HEAD 에 merge 할 일만 남겨 두고 있습니다.  몇 일 전에 freebsd-current에 headsup 메일을 보냈었는데 아직 별다른 거부의사가 없는 걸로 봐서 이번 주말에 commit 할 예정입니다.

Bill Paul 아저씨가 3년도 전에 마지막으로 손대고 제가 처음 compat/ndis/subr_usbd.c 코드를 수정하게 되는 거네요. :-)  영광으로 생각할 예정입니다.

NDIS USB support for FreeBSD 의 코드를 작성하면서 많이 힘들었는데 이제 commit 을 앞두고 생각나는 것은 다음과 같은 것들입니다.

1. USB1 이냐 USB2 냐.
   결국은 USB1 코드로 HEAD에 집어넣을 예정입니다.  USB2는… 글쎄요.  워낙 이슈가 많은 부분이라 아직은 건딜고 싶지 않습니다.
2. NDIS spec
   처음 코드를 작성할 때 NDIS 에 대한 지식이 거의 없었기 때문에 (물론 지금도 거의 없습니다만) 역시 spec 을 모르니 고생길이 훤하다는 것이었습니다.
3. RNDIS 너는 누구냐?
   몇몇 분들이 RNDIS 지원 여부에 대해 말씀을 주셨는데 아직 이번 버전에서는 지원하기 어렵다고 말해 드렸습니다.  사실 어려운 이유는 제 개발 환경이 재현할 수 있는 환경이 아니며 아직 지식이 부족합니다.
4. USB protocol analyzer 가 가지고 싶습니다.
   USB 코드를 작성할 때마다 느끼는 거지만 정말 정말 USB protocol analyzer가 가지고 싶더군요.  L사에서 만든 건 너무 비싸서 (몇천만원) Beagle 단어가 들어간 녀석을 구매하고 싶었지만 그 역시 가격이….
5. 아는게 없으면 몸으로라도.
   세상은 참 넓으며 알면 알수록 모르는 지라 항상 겸속하여야 합니다.

이제 사용자들이 직접 사용할텐데 계속 문제가 발생할 듯 하며 그에 따라 maintain 한다고 고생할 듯 합니다.  다른 driver 작성은 참고할 datasheet 라도 있지만 NDIS 이 녀석은 binary 와 싸워야 하는 일이라… debugging 이 만만치 않을 듯합니다.

이제 NDIS USB가 마무리 되면 perforce에 있는 urtw(4)를 손봐야 할 듯 하네요.  시간이 참 잘갑니다.