O HAI THIS BLOG PURPZIEZ 2 B UZED AZ MAH PLESIOUS MEM. :)

2006/12/27

doDesc(HardMAC & SoftMAC);

なんかそれっぽい話題で盛り上がっていたらしい.
[Well, got off?]
livedoor Wirelessのラの字も考えてないWeb屋のネタ帳の誤読記事
livedoor wireless、MACアドレスによる認証を開始--ニンテンドーDSにも対応
セキュリティのセの字も考えてないライブドアの公衆無線LANサービス

何はともあれ,IEEE 802.11を読んでみましょ,話はそれからっす.
['kay, before we start to talk wireless thingy, Get IEEE 802.11.]

で,改訂版.
[BTW, here's improved one.]


無線伝送路として使用する周波数帯域自体が全く別のトコを使うのでIEEE 802.11*準拠*で
特に問題無いけど,現在作成中のこのブツ,ハードウェアの何処にもMACアドレスへの縛りが無い.
完全にソフトウェア側で,強引にやればruntimeや通信中でも変更可能.
かなり反則なハードウェアに仕上っている. :P
[It has no problem b/c it'll be used on not common radio frequency band,
this hardware has no hardware restriction for MAC address.
Its address can be changed even if in runtime.
Say, it really rocks, I thought. :P]

ARPのframe formatの話になるとモノを読んだ訳ではないからなんとも言えないけど,
IEEE 802.11ではAP側はMACアドレスをBSSIDとしてframe format中で使う.
このBSSIDはBSSと呼ばれるAPのサービス範囲に定期的に送信されるbeaconと
STAからのprobe requestに対するprobe responseに付加される事になっている.
これはClass I frameと呼ばれるブツでauthenticationやassociation,
つまり認証や論理接続する以前の段階で送受信が許されている.
[I dunno about ARP's frame format b/c I've not read ARP standard.
But, in IEEE 802.11, AP uses its own MAC address as BSSID.
This BSSID is payloaded on beacon and probe resposne.
These are included in Class I frame, it can be tx/rx-ed before
authentication/association is completed.]

つまり,IEEE 802.11に従う限り,APのMACアドレスを知る為にARPを使う必要は無い.
受信側のSTAをテキトーな周波数で固定して,beaconが捕まえられる通信圏内に入れて,
且つPMD/PLCPが適切な機能を持っていれば,無線伝送路上を行き交うモノはIEEE 802.11の
MACのレイヤーではoctet streamに変換される.
結局,ARPとは異なり,STAがAP側に何も送信せずにAPのMACアドレスが分かる.
これはpassive scan,具体的に言うとMLME-SCAN.requestのScanType==PASSIVEに相当する.
[So, in IEEE 802.11, to get AP's MAC address does not needs to use ARP.
All you have to do is, fixed STA's a channel and move into accress area
where it can grab AP's beacon and proper PMD/PLCP capability, you can
see all frame as octet stream in IEEE 802.11 MAC layer.
So, STA does not needs to transmit any frame to get AP's MAC address.]

更に,IEEE 802.11ではAPのBeaconPeriodを幾つにするかは規定されていない.
が,WiFiなんとかとか言う機関が異なるベンダーから提供されるIEEE 802.11な機器で
相互接続性が保証出来るか否かを検査しているらしい.
一般の消費者が使用するIEEE 802.11なブツがAPとして動作する場合,
100[ms]程度の間隔でbeaconを吐く様になっているらしい.
[And IEEE 802.11 does not specified BeaconPeriod value explicitly.
But WiFi-blah tests their connectivity for different vendor's products.
In general, most of IEEE 802.11 products which can be available for consumer
may transmit beacon every about 100[ms] interval.]

勿論,beacon自体を暗号化してしまう手もあるだろうが,
この辺はまた別でIEEE 802.11[a-z]の内,"せきゅりてぃ"なトコが担当しているので良く知らない.
そもそも暗号化したbeaconに対応しない機器では相互接続性は確立出来無い.
[Of cource, there is a way to encrypt beacon itself.
But it's beyond of IEEE 802.11, it's mentioned in security enhancement group
which is one of IEEE 802.11[a-z].
And you can easy to understand it breaks connectivity.]

単純に,「APがbeaconを吐かなきゃ良いじゃん」とか思ったりするが,それはそれで問題有り.
beaconはAPの存在をSTAに知らせる為のbroadcastなブツであり,
且つTSFタイマと言うAPが刻むBSS毎にuniqueなタイマのtimestampを使用して,
未だBSSに属していないSTAがこのTSFタイマに同期する為のブツとしても使用されている.
これはそもそもIEEE 802.11の規定する無線伝送路での通信手段として,
Ethernetで良く知られる
CSMA/CD == Carrier Sense Multiple Access/Collision Detection
ではなくて,
CSMA/CA == Carrier Sense Multiple Access/Collision Avoidance
を使っているから,BSSに未だ同期していないSTAは自ら無線伝送路にブツを吐けない.
勿論,Collision Avoidanceとは言ってもcollisionする事は考慮されているので,
dot11ShortRetryやらdot11LongRetryってのがIEEE 802.11 MAC MIBには存在する.
[Simply, "No beacon transmit is another way to go", of course no.
Beacon is broadcast one to announce where AP is at all,
and it's for synchronize TSF timer which is unique timer of each
BSS as well.
Well, IEEE 802.11 is based on CSMA/CA, not CSMA/CD AKA which is use
base of Ethernet.
So, STA wouldn't transmit any frame before synchronized BSS.]

それからWEPはその名の通り,Wired Equivalent Privacy.
つまり,有線と同等の"ぷらいばしー"と言う意味.
利用可能な周波数のチャネル数がバカHUBの台数だけしかなくて,
それらのポートが空中に浮いていると思えば良い.
通信路の途中でframeを盗聴するなんて簡単なのがよーく分かるはず.
[BTW, WEP stands for Wired Equivalent Privacy.
Imagine, number of available frequency channel is equal to
number of repeater and everyone can use these repeater.
It's really easy to get other's frame by simply tapping.]

まとめると,リンク先で盛り上がっているMACアドレスによるfilteringって話は,
Frame Control fieldのoctet streamに対する単純なdecoderでしかない
address recognizerの部分をSMEを経由してソフトウェア側で実現しているだけ.
[That MAC address filtering is simple.
It is software implementation of SME of address recognizer
which decode octet stream of one of Frame Control filed stuffs.]

つまり,ハードウェアにヘチョいブツ混じっているのがまず問題なんじゃね?
と言う訳で,みなさんはハードウェアには投資して下さい. :P
[So, the problem is, many dumb hardware are?
Say, pay to get proper/sane hardware, plz. :P]

2006/12/20

sanitize(0xBADC0D); hg.commit(tip);

社内のSH7751Rなボードの開発環境が起動しないアリエナイ状況に陥る.
[T3h old SH7751R dev box didn't boot, ZOMG...]

仕方無いので,ThinkPadにGentoo Linux ~x86を突っ込んだ後に,サクっと
sys-devel/crossdevでsh4-unknown-linux-gnuなクロスコンパイル環境を
仕立てて,"ぷろだくとれべる"で仕上がっている2.4.18ベースのkernelから
patchをテキトーに分離して,キレイキレイしてからdev-util/mercurialな
repositoryにcommitしまくる.
[So, I've installed Gentoo Linux ~x86 to ThinkPad and make it dev box of
sh4-unknown-linux-gnu by using sys-devel/crossdev.
Then, pull'n'split patches from t3h productive kernel src was beased on 2.4.18,
and commit them to dev-util/mercurial repository w/ my stupid code sanitizing.]

更に,以前の開発環境が2.9xベースと言う古代の遺物.
これまたテキトーにcompile fixなpatchもでっち上げた.
取り敢えずzImageが作れる所まで直ったらしい.
[But it won't build due to t3h src depends old toolchain behavior.
So, I've poke it and make zImage build.]

あとはボード上に置いてみてdebug'n'fixするだけ.
時間が余ればupstrteamなpatch repositoryもでっち上げたので
仕事をしているフリをしてbackport遊びをするかもしれない. :p
[The last one is to deploy stuffs on the board and debug'n'fix.
Once IT JUST WORKS(tm), it may be time to backport only for fun. :p]

で,新Greg-KH本が出たらしい. :)
[BTW, New Greg-KH's book is now available, I heard. :)]
New book explains how to build Linux 2.6 kernels (LinuxDevices.com)

2006/12/12

Draw(SoftMAC & HardMAC);

IEEE 802.11/IEEE 802.11aのMAC/PHYの辺りのイメージ.
SoftMACのフローチャートまで手を付けられなかった.
納期がヤヴァい. :P
[Here's my stupid image of IEEE 802.11/IEEE 802.11a MAC/PHY.
Well, I'd have to stuff completely SoftMAC flow charts, though.
Umm, blah. :P]



修正:
Network SubsystemとかPCI DMAとかも.
Ring BufferとかARP Cache本体とかを書く場所が無いなー. :P
[FIX:
Forgot to add Network Subsystem and PCI DMA or so.
Oh well, there is no space to describe Ring Buffer
and ARP Cache itself. :P]



修正:
変な所に在ったIEEE 802.x LANをIEEE 802.3として分離.
IEEE 802.1 BridgingとIEEE 802.2 LLCを追加.
ねむー. :P
[FIX:
Separated IEEE 802.x LAN as IEEE 802.3 for example was wrong placed.
Added IEEE 802.1 Bridging and IEEE 802.2 LLC.
Well, SIGZZZ. :P]

2006/12/11

goto t3h_Y; t3h_Y: doTT4(SoftMAC & HardMAC);

当初はハードウェアな人間だと思われていたらしいが,
何時の間にかソフトウェアな人間だと言われて,
更にそっち系のメンバーが不足していたとの事で
便利屋且つ厄介者として扱われる今日この頃. :P
先週は木曜日にYなトコロで主にハードウェアのレビュー,次の日にP4のミーティング四回目.
[My bosses thought I was hardware-oriented, though I'm now
deemed software-oriented.
To make matters worse, my office lacks software-oriented ones.
So, I act like the handy man, otherwise like nuisance. :P
Last week, the Thursday is a review of hardware specs @ t3h 'Y'.
Then, Friday is 4th meeting of P4.]

レビューにて,お客さんはRadio Frequencyな人らしく,
ハードウェアの方にはAGC/LNAな感じで突っ込みが厳しかった.
逆にソフトウェアの方はお任せな感じだった.
曰く,「聴いてもヨクワカラナイ」からとか. :P
[The reviewer is really Radio Frequency guy, he pointed at AGC/LNA thingy.
But he'd let leave up me about software thingy.
B/c, he said "Well, I'm unprofessional that thingy as you know." :P]

ミーティングにて,結局,自分がSoftMACのフローチャートを書く事になった.
以下,メモ.
[On the meeting, it made me have to design SoftMAC implementation.
The follows are P4 iff SoftMAC.]
 * P4 iif SoftMAC
+ active scanning
+ best-effort hand-off
+ misc MLME ioctl(2)
+ misc PLME ioctl(2)
で,高専の頃,誰かが言っていた事を思い出した. :P
「エラい人の言葉でも専門外の事だったら疑ってかかれ」
[So, I'd have to say a phrase that I heard I was a student of ONCT. :P
"You should doubt what someone said, even if he was your guru,
especially when he mentioned about unprofessional thigy."]

修正: typoとか.
[FIX: Typos or so.]

2006/12/06

ISE[8][2][i].karma--;

今日はBPFを弄った.
要求としては16MHzキャリアに乗っている5MHz帯域の信号を
エイリアシング/イメージングから保護する事.
[I've Poked the BPFs.
Requested spec is to attenaute aliasing/imaging
for 5MHz band signal on 16MHz carrier.]

DCと32MHzにアレが出て来るって事を考慮しただけだと20次で良さ気なモノが出来た.
一応,実績のある過去の設計仕様では48次で作っているブツがあったので,
48次を限度に低周波減衰域/高周波減衰域を広く取ったブツも作った.
[Simply to attenaute DC and 32MHz ones required 20 deg.
Some referenced previous designs used 48 deg, so I've tried
to enlarge high/low attenaution band w/ 48 deg as well.]

で,XilinxのISE 8.2iでジェネってみた.
んー,使い方がヨクワカリマセンネー.
ツールの名前だけ見るとFIRをジェネる為のブツが二個有るみたい.
仕方無いので英語なマニュアル約40ページと約60ページを印刷.
明日はYなトコロに出張予定なので行き帰りにでも読むつもり.
[Then, I've tried to generate w/ ISE 8.2i.
Blah, that's really bloated and enough to confuse.
So why does it have 2 FIR code gen?
Well, I'll read about 40+60 page manual written in English,
though on the way to and from t3h 'Y'.]

で,そこそこsys-apps/qingyに人気が出てきたっぽいし,
dev-libs/DirectFBもPV==1.0_rc2なので,
中身はC++だけど,コンパイル時間がそんなに要らない
x11-misc/slim-1.2.6に乗り換えてみた.
その内,自分用のテーマを作る.
[My minor oriented karma force me not to use sys-apps/qingy,
due to dev-libs/DirectFB's PV==1.0_rc2.
The replacement is x11-misc/slim-1.2.6 is written in C++ though,
not takes so long time.
So, I'll make my own theme sooner or later.]
Bug 107526 x11-misc/{slim,slim-themes} - new ebuild

あ,Splashyってのもあるのかー. :P
[Oh well, Splashy is, too. :P]
Splashy

MATLAB.karma--;

SoftMACの部分が一段落しつつあるので,新しいトコに着手.
マルチキャリアの直交変復調近辺のデジタルフィルタの設計.
んー,一年振りのz変換は或る意味,新鮮だったりする. :P
[SoftMAC thingy is mostly DONE, then I'd poke next thingy.
The ones are design digital filter which is implemented
before/after quadrature modulation/demodulation.
Hmm, the "z transform" is much nicer, after an absence of
a year. :P]

ダウンサンプラ/アップサンプラの前段/後段にかますLPFを弄った.
このLPFは,エイリアシング/イメージングを抑制する為のモノで,
前段/後段のサンプラと合わせて,デシメータ/インタポレータと呼んでいる.
[Well, I've poked LPFs before/after down-sampler/up-sampler.
These LPFs attenuate these samplers' aliasing/imaging.
These combined ones are so-called decimator/interpolator.]

MATLABの低品質なUIと自分の巨大なappsを扱えない憶えの悪さが禍して,
フィルタ設計ツールの使い方を理解するまでに一日.
z変換と離散時間制御と離散時間信号処理の復習に半日,
デシメータ/インターポレータの原理とFPGA上での実現方法の勉強に半日.
[Due to MATLAB's suck UI and bloat, it takes 1 day
to realize how to use filter designing tools for me.
And then, restudy about z-transform, control theory and signal
processing of discrete time domain, that takes half of a day.
Studying about functionalities and implementation techs
of decimator/interpolator, that takes another half of a day.]

出来上がったインターポレータ/デシメータは,
インターポレータ
= (2xアップサンプラ + 50次等リプルLPF)
+ (8xアップサンプラ + 14次線形補間LPF)
デシメータ
= (8xダウンサンプラ + 54次等リプルLPF)
+ (2xダウンサンプラ + 6次等リプルLPF)
[Finally, I've designed like this,
Interpolator
= (2x up-sampler + equiripple LPF of 50 deg.)
+ (8x up-sampler + linear interpolation of 14 deg.)
Decimator
= (8x down-sampler + equiripple LPF of 54 deg.)
+ (2x down-sampler + equiripple LPF of 6 deg.)]

で,中ではParks-McClellanアルゴリズムと言うRemezアルゴリズムと
Chebyshev近似を併用したブツを使っているらしい.
IEEE 802.11のMAC部分はLinuxに実装があるけど,
PHY以下は殆んどデバイスの仕事だしRFにも依存するのでソフトウェアで実装するとか
アレな真似をしている人は居ないのかも.
HDL設計/コーディングでは期待値検証に使えそうな感じはするけれど,
控えめに見積もってもシミュレーション程度にしかならないからかな? :P
[BTW, internal of that designing tools use Parks-McClellan
algorithm which is combined Remez algorithm and Chebychev
approximation, I heard.
Linux has a IEEE 802.11 MAC part implementation though,
these is no implementation one which is under PHY thingy.
Well, I know that "under PHY thingy" is hardware functionalities,
and it depends on RF part.
Their use is only for a expectation collation for HDL, or simply
for its simulation. :P]

明日は直交変復調の前段/後段のBPFを弄る予定.
[Hmm, tomorrow, I'll poke BPFs which is implemented before/after
quadrature modulation/demodulation.]

2006/12/01

doTT3(HardMAC & SoftMAC); dosomethings2();

P4のミーティング三回目.
んー,なんか結局,開発に参加してもらう方,約二名に
IEEE 802.11な英文を読んでもらう事になってしまった.
ま,被害者^H^H^H仲間が増えるだけなので問題無し. :P
[P4 meeting 3rd.
Hmm, co-devs will read the IEEE 802.11 one.
Well, they look like victims^H^H^H^H^H^Hambitious. :P]

で,USE="xcb"は鬼門ですねー.
x11-terms/xterm + app-i18n/scimとかjavaのpluginがぶっ壊れるっぽい.
一応言及しておくとXCBが悪い訳ではなくて,twice lock/unlockとかしている
appsの方が阿呆過ぎなだけです.
Momongaでは一時的な対策(?)として,twice lock/unlockをassert(3)で
検出している部分をコメントアウトすると言うパッチまで用意してるし,それはマズくね? :P
CFLAGS+="-g" + USE="debug"なx11-libs/*をでっち上げて,
upstreamのpatchを幾つか拾ってきたので,暇な時に直す予定,多分. :P
[BTW, USE="xcb" really l^Hrocks.
x11-terms/xterm + app-i18n/scim and java plugins are bombed.
FYI, that isn't XCB's fault b/c some apps try twice lock/unlock itself,
these crappy code shoudl be shot.
OTOH, Momonga ab^H^Huses a patch which deletes assert(3) for invalid
twice lock/unlock. :P
So, I prepared x11-libs/* w/ CFLAGS+="-g" + USE="debug" to fix it.
I'll poke something sooner or later, maybe. :P]

で,net-misc/dhcpcd-3.0.0も鬼門ですねー.
uberlordさんがcomplete rewriteしたのでKEYWORDSが一度外されて,
ちょこちょこ追加されているのだけれど,htonl(3)をサボっている箇所で
little endianなホストが刺さったっぽい.
一応,パッチは公開されているが,今はbugzieが死んでる,新しいのになるっぽい.
[Then, net-misc/dhcpcd-3.0.0, IT JUST WORKS(tm).
uberlord did complete re-write, and droped KEYWORDS.
But, there are some limbos of endian consideration,
so no htonl(3) is IT DOESN'T WORK(tm) on little endian host.
There is byte-order fix patch, but bugzie is now dead, for resurrection.]

で,遂に需要の少なそうなブツを公開. :9
dev-util/mercurialでclone出来ます.
[Yay, a little demanded one is finally out. :9
You can clone it w/ dev-util/mercurial.]
$ hg http://dev.gentoo.gr.jp/~hiyuh/cgi-bin/hgweb.cgi portage
hiyuh's misc Portage Overaly

追記:
bugzie復活したっぽい.
net-misc/dhcpcd-3.0.1が突っ込まれたっぽい.
んー,ねるー. :P
[ADD:
Bugzie is resurrected.
net-misc/dhcpcd-3.0.1 is added.
Well, SIGZZZ. :P]

2006/11/28

GentooJP.NomiKai--; /* LDAP */

11/26のLDAPな飲み会は寝過ごしました,すいません.
忘年会は寝過ごさないように気を付けます. :P
[hmm, I've overslept the LDAP-favor NomiKai, sorry.
Well, I'll be no late next NomiKai AKA BouNenKai. :P]

で,x11-libs/libX11とmedia-libs/mesaにUSE=xcbが導入されてます.
XCBってのは,コレ.
[BTW, USE=xcb is added to x11-libs/libX11 and media-libs/mesa.]
XCB Wiki
XCB (Wikipedia)

現在,build_with_useが抜けているので,気を付けましょう.
[However, these have a silly build_with_use bug, so be careful.]
bug #156397

2006/11/25

Office.NomiKai++; /* Nov. */

11月分,月末飲み会でした.
社内でピザ -> 飲み屋に移動 -> 駅前のカラオケのコンボ.
あー,喉がー,喉がー. :P
[Today is a NomiKai of end of Nov,
pizza in the office -> NimiYa -> KaraOke.
Hmm, I have a scratchy throat, though :P]

2006/11/23

doTT2(SoftMAC & HardMAC); doSomethings();

P4のミーティング二回目.
今日までのアクションアイテムはこなしたつもり.
次のミーティングまでに課せられたアクションアイテムはちょっち手強そうな感じ.
しかし,やるしか道は無し,っと. :P
[Today, I had 2nd meeting of P4.
I've done my action items for this one.
However, I have to do some time-consumings for next one.
But yes, only what I can do is to do it, anyway. :P]


他人の吐露を見ておいて思う事がありながら,書かない事は失礼なんだろー,
と時々思うので書いてみる.
[It's a bit of unfair for me that what I only saw other's mumbles
even if I'd have to mention that thingy.
So, here we go.]

Chofu-sai (AO diary)
「せめて現役の学生さんに幸せに働く卒業生像を見せてあげたい.」
["I'd show that some OB really fun his works for these students."]

仕事が面白過ぎて日付が変わる前に帰宅するのに苦労しております. :P
[Well, I'm really fun my works.
Every time I have to leave work due to dateline coming,
I feel my heartbreak. :P]

記憶に残っている,うちの社長語録には,
「食う為にこの手の仕事をやるつもりなら,それは諦めた方が良い.
楽してそこそこ儲けたいなら,他にもっと良い仕事がある.」
って言うイカす台詞があった.
[IIRC, my boss said,
"If you would work for clothing/food/housing, we can't recommend that doing.
For have an easy life, there are many other way to go."]

OSM亡き後どうすんのかという話 (みんな仲良しのつもり)
「開発をやってる電通大からは外にCVSが出来ないという凄い問題があるので
リポジトリのアップデートが非常に面倒だったりする。。」
["UEC's network doesn't allow to me to access CVS repos, how annoying..."]

それ,自分もすーぱー困ってました. :P
ポリシー上仕方の無い処置だったのかもしれないケド,
その辺りに詳しい管理者でもないので何ともならなかったなー.
[Yep, that was really PITA, too. :P
Due to their policy, it might not help, though I'm not sure about that truth
b/c I was not one of that admins.]


Officeの機能は思考を規定する (備忘録)
「結果としては、引出しは多い方が良い、ITリテラシーは高いほうがいい、
というつまらないことなんだけれど、Officeに進化は必要か、といわれれば、
引出しが増えるような進化が必要だと言いたい。
ちなみに、文書フォーマットがXMLになればPerl/Ruby/PythonでExcelを
もっと処理しやすくなるから進化歓迎!なんていう意見もあるけどね(笑)」
["As a result, to add more option would be good, to have highly IT
literacy as well.
So, I'd like to say to add more options is needed as Office's innovation.
BTW, once it change its format to XML, Perl/Ruby/Python make it easy to
poke its data, so that 'if' is much nicer, LOL."]

個人的に引出しを無駄に多くする事は歓迎出来無い,
他人から手取り足取りで教えられたツールの使い方を溜め込む記憶力を"あいてーりてらしー"とは呼びたくない.
辞書は必要充分なインデックスで必要十分な中身が取り出せれば良いと思う.
最後の一文はちょー賛成,表計算するのにマウスでカチカチカチカチやりたくない.
そして,イルカはカッコいい! :P
[IMHO, to add many option is not so better thing.
I wouldn't define to stuff about giving every possible help
how to use one tool as a comp-literacy.
All dictionary should contain 'if and only if' indexes and
'if and only if' contents, I thought.
The last line is what I'd always have to say.
To click many times to calculate something is really annoying me.
BTW, that dolphin really rocks! :P]

現代に跳梁跋扈するWIMPyなGUIに対して,ARG曰く,
「その主たる理由は,一般大衆市場におけるコンピュータの経済的な成功であり,
この市場を構成する大部分は素人である.
我々は,この状況を変え,玄人の為のグラフィカルユーザーインターフェースを提供する.
勿論,我々はこの様な事がすき間産業然としている事は十分承知している.」
[Nowadays, there are many WIMPy apps, ARG criticized,
"The main reason has been the economical success of computers
in the normal consumer market, which consists of unexperienced users mainly.
Our motivation is to change this situation and to provide a graphical
user interface for experienced users, though we know that this market is
a niche. "]

Javaでソートアルゴリズム (WEBLOG SIDE)
qsort(3p)と{b,h,l,t}search(3p)で"ぎぶあっぷ"です. :(
比較関数は,比較対象2要素のvoid*からの適当なキャストと
return + カスケード条件代入文で論理SLOC 3で終了です. :)
[qsort(3p) and {b,h,l,t}search(3p) is enough for me. :(
Any compare function is constructed by,
sane casting for 2 arguments and
return + cascaded conditional substitution.
These are only logical 3 SLOC, period. :)]

2006/11/17

a result of my jaw

今日は例のP4の実質的な開発方針を決める為のミーティングでした.
色々リスクの種はあるけれど,始まっちまえばつっ走るだけだから,
何とかなるっしょ? :P
[Today, I attended a meeting of t3h P4 dev-direction.
Well, it may have some pitas, though all I can do is
just do it if the project is runnig. :P]

実質的なミーティングの後,無駄な余裕が出てきたのか,やはりオフトピになる.
色々ムニャヘニャ文句を言った結果,上司の方が,
「P4が終った後に,あのCPUボードとFPGAボードとAD/DAボードのセットで,
upstreamなLinuxの開発環境をムニャる社内プロジェクトっぽいモノを考えておく」
みたいな事を言われた.
[When the meeting was over, I jawed some of OTs.
So, a my boss mumbled like,
"Okay, like you said, we may plan a private project
that's for creating upstream-flavor dev-env of Linux on
our CPU+FPGA+AD/DA board-set, after the P4 was over."]

アレなスケジュールではP4は来年二月,遅くとも今年度末にはケリをつけたいブツなので,
始まるとすればそれ以降になるけど,ちょー期待,まだ口約束だけどな! :DDD
Gentooが云百万のFPGAを制御する日は近い,たぶん. :P
[Hmm, according to the P4's schedule, that will be over
until Feb. or so.
Then, the awesome plan will start, I hope.
But it's still verbal one, though! :DDD
So, we'll see FPGAs which is really expensive and Gentoo's
collaboration, I guess. :P ]

2006/11/16

Merge(&EixTrunk, &MyPatches); Exchange(&PB.battery);

昨日,貼ったばかりのapp-portage/eix-0.8.1のパッチが速攻でマージされた. :)
テキトーに符号付き/符号無しの警告を黙らせていた所をまともな修正に変更した以外は,
全部current svn trunkに突っ込んでもらえたみたい.
[Yesterday, I filed warning silence patch of app-portage/eix-0.8.1
bugzie, as you see.
Then, the dev quickly review'n'test that stupid ones and did merged
to current svn trunk, except my wrong singed/unsigned pokings.]

で,マニュアルdiff(1)で生成したパッチをcat(1)でテキトーにまとめて貼ったもんだから,
Subversionの使い方が分かっていない事がバレたっぽい,howto書かれているし.
取り敢えず,Mercurial使いなのだと言い訳をしておいた. :P
[And then, he realized I didn't know use of Subversion b/c that was
cat(1)-ed from manually diff(1)-ed ones.
So, he suggested me to use of it by mini howto.
Well, I had to say I'm a user of Mercurial, not Subversion, though. :P]

Gentoo/PPCなPowerBookのバッテリがAppleの交換プログラムに該当していた.
以前からしっかり筐体に嵌まらないから変だなーとは思っていたが不良品だったとは.
取り敢えず,タダなので交換の手続きをしておいた.
んー,良く見るとバッテリのパッケージの境目が気持ち黄色っぽいのだが気の所為か? :P
[BTW, my Gentoo/PPC PowerBook's battery was one of defective ones,
as Apple announced already.
Hmm, I already got suspicious due to this one didn't fit precisely its main frame.
This exchange program is no charge, so there is no reason of to do it.
Umm, If I made attention to see this one, its boundary lines look like
bit of yellowish, though. :P]

2006/11/15

doTT(HardMAC & SoftMAC); eix.warning--;

と言う訳で,8時間程かけてHardMACとSoftMACの極意を伝授された. :P
明日からは仕様書をムニャる予定.
[Today, I've been transferd technical thingy of HardMAC and
SoftMAC from my bosses.
Well, it takes 8 hours or so, though. :P
Next, I'd have to note some detail of its spec to the sheet.]

app-portage/eixの警告が何かに気に入らなかったので直してみた.
0.8.1がportageに入ったので,bugzieに貼っておく. :P
[app-portage/eix has ton of warnings, so I've fixed some of these.
And 0.8.1 was out, it needs to fix official ASAP. :P]
silence warnings when compiling app-portage/eix-0.8.1

2006/11/14

+ (dot11 | MAC & PHY) * (1.0 / 4.0);

"IEEE802.11 MAC and PHY"な"すたんだーどどらふと"(?)を更に1/4程消化.
直接ナントヤラと赤外線なPHYなので,残り半分はすっ飛ばした.
明日,上司の方にHardMACとSoftMACの境目を教えてもらったら,
ブツの仕様書を書く事になっているけど,どーなるんでしょーかー? :P
["IEEE802.11 MAC and PHY" as known as the standard
draft, plus about 1/4 is DONE.
DS thingy and InfraRed thingy of PHY are skipped as a 1/2 of
that draft.
Tomorrow, once my bosses tell me about boundary of HardMAC
and SoftMAC thingy, I'll do write down its spec or so.
Well, who knows what will happen? :P]

で,感想.
重要なのは分かるけど,backward-compatって新しくモノを作る時は,
大方足枷になるっぽい.
アレなbackward-compatな仕様だったので読むのが大変だった.
と言う訳で,Abandon! Abandon! :P
[My impression is,
I know a backward-compat is a really important thing, though.
But those many considerations drive me nuts, I'd have to say.
All I would say is "Abandon! Abandon!" :P]

2006/11/11

(dot11 | MAC & PHY) * (1.0/4.0)

"IEEE802.11 MAC and PHY"な"すたんだーどどらふと"(?)を1/4程消化.
しかし,当然英文なのでボロクソに読むスピードが遅い.
やっとauthenticationとかassociationの意味が分かってきた.
mobilityが分かってないとイカンのね,何を言っているのか分からなかった訳だ.
と言うか,MSDUとかIFSとかDCFとか...acronymが多過ぎ. :P
[I'm reading "IEEE 802.11 MAC and PHY" as known as the standard
draft, about 1/4 is DONE.
But, yes, my speed is really slow due to these are written in English.
Finally, I realize the authentication and the association thingy,
to understand it requires to know these mobility thingy, damn it!
BTW, that stuff has many acronym like MSDU, IFS and DCF or so,
these are enough for me to do limbo, even if when I'm reading it. :P]

OFDMな部分も一通り読んだ.
理解出来無い話じゃないけど,一つ気付いた事は数学の知識がかなり忘却の彼方に逝っているっぽい事.
使わないと忘れるとは良く言われるけど,実体験するとは思わなかったなー.
[At the same time, I'm poking OFDM thingy.
That stuff is not quite difficult for me, though.
But I'd have to say I really forgot some mathematics thingy even I was
good at ones.
As it is often said,
"Once you didn't use it, you'll forgot use of it, even if you were good at it."]

えーと,例え話にすると,
彼の狩人,仙道に入りて徳積む事幾星霜,鳥を射るに弓矢使わず.
麓の里にて弓矢を示し,「これは何の道具か?」と訊いたそうな. :P
[Well, so like that,
A hunter, he want to become hsien and he did train harder'n'harder in mountains.
Finally, he can do shoot a bird w/o bow'n'arrow, then he went down mountains.
When he saw a bow'n'arrow in a store of a village, he pointed it and asked,
"Hmm, what's that for?" :P]

2006/11/09

God kills a kitten...

#gentoo-bugsにて.
[From #gentoo-bugs snippet log.]
11/09 04:44:01 jeeves
[New Bug] https://bugs.gentoo.org/154496 nor, P2, All,
ejs76@conceptsfa.nl-bug-wranglers@gentoo.org, NEW, pending,
nvidia-drivers-9742-beta have been released
11/09 04:44:25 jakub
ZOMG!
11/09 04:44:59 Opfer
Jiiiiha
11/09 04:45:33 jakub
where's the 0day kitten link
11/09 04:47:04 Faustov
dunno but i got an f1 crash link: http://warpdrive.se/upl/30527.jpg
11/09 04:47:18 jakub
lol
11/09 04:47:24 Faustov
:)

11/09 05:02:38 hiyuh
jakub: http://allen.brooker.gb.net/misc/kitten-0day.jpg
11/09 05:03:00 jakub
hiyuh: ty; already found it in bookmarks
11/09 05:03:05 hiyuh
lol
11/09 05:04:21 hiyuh
http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
11/09 05:04:44 jakub
ahahahah!
11/09 05:05:39 jakub
bonsaikitten: ^^^ :D
11/09 05:05:50 zlin
haha
11/09 05:07:10 *
bonsaikitten segfaults
11/09 05:07:17 armin76
lol
11/09 05:07:28 hiyuh
needs to gdb him

dig(DMA.alloc_methods);

今日は,"どっといれぶん"なヘッダを調べつつ,ドライバのDMAな部分に着手.
取り敢えず,念頭においておかなけれならない事は二つ.
[Today, I've poked "dot-eleven" header structure and DMA thingy.
So, DMA thingy has 2 points.]
  • デバイス側のDMAコントローラの動作に従う必要が有るので,
    DMAでアクセスすべきメモリ領域の配置に制限を加える事になる.
    [Deu to limitation of device side DMA controller,
    we have to restrict these memory mapping.]

  • 実メモリが不足しがちなハードウェアだと,DMAなメモリ領域を動的に,
    且つ細切れで確保すると色々面倒.
    [On small memory hardware, dynamic allocation of fragment
    memories will became only PITA.]

ま,userlandで無駄に*alloc(3)する事と話は変わらないって事ね.
[All I can say is that points are similar to use of *alloc(3)
in useland.]
/* A consistent allocation */
uint8_t essential_memory[SIZE_OF_REQUIRED_MEMORY_IN_OCTET];

/* do somthing here. */

[Or,]
/* A dynamic allocation */
uint8_t *p_essential_memory;

p_essential_memory =
(uint8_t)malloc(
sizeof(uint8_t *)
* SIZE_OF_REQUIRED_MEMORY_IN_OCTET
);
if (p_essential_memory == (uint8_t *)NULL) {
/*
* You should do recover allocation failure anyhow,
* Otherwise, you have to give up.
*/
}

/* do something here. */

free(p_essential_memory);

やっぱり,*alloc(3)にはそれなりの使い方ってのが有る.
オーバーヘッドや繁雑なエラーハンドリングをする苦労をしてでも,
動的にメモリを確保したい場合にだけ使うべき.
[So, use of *alloc(3) depends on its needs.
Whan it uses *alloc(3), it should have some reason
for costs of that overhead and coding error handling.]

仮にオーバーヘッドを気にしない用途だったとしても,
エラーハンドリングを怠っているとSIGSEGVを喰らったり,
"せきゅりてぃほーる"を作るだけ.
manページを読めば分かるけど,OOM killer,所謂メモリ不足解決器も居るし.
[If it's no matter to have some overheads, lacking error
handling produce SIGSEGV annoying, dumb ass^H^H^Hsecurity holes.
To make matte worse, OOM killer is, which is a out of memory beast,
according to man pages.]

これがデバイスドライバのDMAなメモリ領域になると,
大方は連続な領域を確保する必要が有るので,
安直にタイマ無しで動的にメモリ領域を確保しようとすると簡単にロックアップする.
[If we'd talk about device driver's memory allocation,
DMA needs to reserve continuous physical memory.
So, trying reserve it w/o timeout is a easy way to lock-up.]

結局,動作中にDMAなメモリ領域確保に失敗すると話にならないので,
initializeな部分でDMAなメモリ領域を適切な方法で予約して使いまわす.
モジュールと言うportabilityを犠牲にしてもドライバをrobustにしたければ,
メモリマップを変更してしまうと言う荒技もあるが,それは反則なんだと. :P
[Thus, failure of dynamic allocation for DMA is totally nonsense
as a point of view of driver's robustness.
A way to go is reserve memory as sane DMA mapping when it do initialize.
If you really want to completely robust driver and you're ready to
sacrifice its modularize portability, you can do re-map canonical
memory mapping, though.
Of course, I'd have to say it's just abuse. :P]

2006/11/08

A SNS so-called MySpace

取り敢えず,作ってみた.
変なSNSですな. :P
[Well, done.
That's bit of subtle, though. :P]
hiyuh's MySpace

2006/11/07

(hasFW(&ORiNOCO) && hasFW(&Prism54)) ? P4.curse++ : P4.curse--;

例のプロジェクトP4,イイ感じに雲行きが怪しい! :X
[That project P4 really su^H^Hrocks! :X]

今日は,ORiNOCOとPrism54なチップの詳細を調べていた.
と言うのは,MACとPHYを突っ込んだFPGA向けにドライバを書く事が一番のTODOなのだけれど,
大体の802.11a/b/gなチップってのはPHYが物理的に論理回路の形で存在して,
MACの半分はembeddedなCPUとは別の内部プロセッサが担当していて,
更にfirmwareを利用して残り半分のMACを実装しているっぽい.
[Today, I've dug ORiNOCO and Prism54 thingy.
Because, my bosses' plan has writing driver for the FPGA which is implemented
our PHY+MAC IP as first TODO.
But, almost of 802.11a/b/g chips has PHY as logical circuit,
and a half of MAC is small embedded processor, the half of MAC is firmware, IIRC.]

で,その半分の中にauthenticationとかassosiationとかの部分が入っているみたい.
うへ,この俺様チップにはembeddedな内部プロセッサは無いがな.
しかも,firmwareが逆アセンブルなソースやS-Recode形式でしか
お目にかかれないって,ヤバくね? :P
[Then, that MAC part has authentication and association thingy.
Well, our FPGA has no internal embedded processor, though.
And to make matter worse, these firmware can be available as only disassembled
source or S-Recode stuff, ZOMG. :P]

ま,何とかするしかないので,引き続きモニョる予定.
[Hum, all I will do is only do it, though.]

Note(&SKorea[4]) ? FlightBack(&me) : CrackUp(&me);

韓国四日目.
"みょんぼん"(?)と言う所のLOTTEの免税店に行ってきた.
が,"ぶらんど"なブツとかしか見当たらず,何も買えず仕舞い. :(
結局,空港で15万ウォンの茶器セットを実家へのお土産に買いました,
日本円で言うと2万円弱位.
雨が降っていて微妙な天気だった所為か,帰りの飛行機は横に揺れてた.
明日からは何時も通りに仕事.
[SKorea 4th day.
We went to LOTTE's duty-free store of "MyonBon"(?).
However, there are many brand-ed stores, but only like that.
So, I couldn't bought any souvenir. :(
Finally, I bought tea set which is priced 150,000 won for my parents.
FYI, 150,00 won is about 20,000 yen or so.
Well, it was rainy in SKorea, so the aircraft which we were boarding
were rolling somehow, though.
Tomorrow, we'll go on with our working day.]

今回の旅行の感想,「キムチ,一生分喰ったんじゃなかろうか?」 :P
[The summary of this trip is "We can't eat Kimchi any more, I guess?" :P]