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]