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

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

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

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

이와 관련하여 저에게 닥친 가장 큰 이슈는 역시나 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 사에서 나온 분석기이며, 가격은 $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)는 처음 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)에게 무한 감사 드립니다.

기부 받습니다. 

오후에 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에서 보실 수 있을 것입니다.

근데 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 하지 않은 것들이 몇 개 있는데 이제 좀 더 편하게 할 수 있을 듯 합니다.

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 가 계속 불평을 할 듯 합니다..  의외로 신경이 많이 쓰입니다.

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)를 손봐야 할 듯 하네요.  시간이 참 잘갑니다.