libc の変更点



 C言語の標準ライブラリ。広義にはPOSIXの実装を指す。
 
 * 見解 [#n2805614]
 
 - Monaは従来の枠組みにはとらわれない視点で実装を進めるため、POSIX準拠を推し進めることはしない。
 - 第三者が実装するのは大歓迎。
 
 * 移植 [#g80c4410]
 
 - 一般に流通しているコードはPOSIX前提のものが多いため、移植にはlibcが不可欠。
 - 移植の際には足りない関数を自前実装する羽目になるのが現状。
 
 * 実装 [#kd7591cf]
 
 - [[MonAPI]]
 -- 基本的には独自のクラスライブラリだが、最低限の汎用関数が実装されている。
 --- <monapi/syscall.h> malloc, calloc, realloc, free, printf, exit
 --- <monapi/string.h> memmove, memcmp, memset, strlen, strcpy, strcmp, memmove, memcmp, memcpy, strncpy, strcspn, strspn, strtok, ltona, strcat, strstr, strncmp
 -- MonaMain()はC++依存だが、独自にcrtを書けばC形式のmain()からスタートアップさせる(ように見せかける)ことは可能。
 --- monapi_impl.cppにargv生成の支援が入っていて、スタートアップからmainを渡してコールバックさせる仕様。
 --- tmpmonalibcにcrtが含まれる。
 - [[monalibc>Manual/monalibc]](注:ヘッダ名が現状と異なる)
 -- [[shadow]]氏による実装。公式に取り込まれている。
 -- 以下の関数が実装されている。
 --- <monalibc/ctype.h> isalnum, isalpha, isascii, isblank, iscntrl, isdigit, isgraph, islower, isodigit, isprint, ispunct, isspace, isupper, isxdigit, toupper, tolower
 --- <monalibc/math.h> sin, cos, tan, sqrt, atan2, atan, acos, modf, floor, log, log10, exp, pow, ceil
 --- <monalibc/stdarg.h> vsprintf, vsscanf
 --- <monalibc/stdio.h> sprintf, sscanf
 --- <monalibc/stdlib.h> strtol, strtoul, strtoi, atoi, itos, itosn, ftos, abs, labs, div, ldiv, qsort, bsearch
 -- MonAPIとは分離されているので、使用時には別途リンクが必要。
 - [[monacapi>Yui_Neko/Cライブラリ]]
 -- [[Yui_Neko]]氏による実装。gccだけでなくVC++にも対応。
 -- MonAPIやmonalibcは一切使用していない独立した実装。
 -- libcだけでなくMonAPIのC言語版(名前の通り)やSDLのサブセットも含まれている。
 - [[tmpmonalibc]]
 -- pol氏による実装。monalibcを補完。
 -- [[Mesa]]の移植のためリンクに必要な関数だけが実装されている。
 -- main()からスタートアップさせるためのcrtが入っている。
 
 * 今後の展開(案) [#d3a21dc4]
 
 - 独自にバラバラな実装が乱立するのは無駄が多く混乱するだけなので、何らかの形で集約することが望ましい。
 - スクラッチから作るのは大変なのと、POSIX互換OSを自前実装するのが目的ではないので、既存の実装を持って来ることが望ましい。
 - 比較
 |glibc|LGPL|Linuxとセットで使われるため最も有名。ライセンスが焦点。|
 |[[newlib]]|[[BSD-like:http://sources.redhat.com/newlib/COPYING.NEWLIB]]|組み込み向けのためコンパクトで扱いやすい。Cygwinでも採用。|
 |*BSDのlibc|修正BSD|本格的なPOSIXレイヤを作るのでなければここまでいらないかも。|
 
 ** コメント by ひげぽん [#g86c0425]
 libcに関して~
 最近移植の際にlibcがネックになっているのは気づいていました。この件、まとめてくださった方ありがとうございます。基本的には私が中心になってlibcの移植を進めていくのはMonaの初志から外れるので難しいです。~
 ですが、他の方々がlibc移植をおこなってくださるのであればそれは大歓迎ですし、カーネル・システムコールの協力が必要であればできる限り協力したいと思っています。~
 
 
 libcの選定に関して~
 基本的には、libcを移植して下さる方の推薦するものをOKかどうかを検討する形が良いと思っています。~
 (移植する方の労力・やりやすさ・考え等々を尊重したいです。)~
 軽い印象だと~
 -glibc⇒巨大、ライセンスが微妙
 -newlib⇒割とコンパクト、ReadMeを読んでみたが特に違和感はなし。
 -*BSDのlibc⇒ newlibとの規模差がまだよく分かっていない
 
 Monaに散在するlibcとの兼ね合い~
 libcがきちんと移植された暁には、MonAPI内の一部関数は廃止, monalibcはshadowさんの了解を取ってサブ扱いとなるのが良いと思っています。~
 monacapi, tmpmonalibcもそのような感じで。~
 
 
 以上です。libc移植に際して私の意見や判断が必要なことがあればご指摘いただければ幸いです。
 
 
 
 
 * コメント [#cf565159]
 
 #comment(below)
 - ご意見ありがとうございます。junjunnさんや、ななしさんの丁寧な説明で現在の問題点が少しずつ分かってきましたのでなるべく早く方針を決定したいと思います。-- ひげぽん~
 ちょっと今後のライブラリのあり方を整理させてください。~
 - ご意見ありがとうございます。junjunnさんや、ななしさんの丁寧な説明で現在の問題点が少しずつ分かってきましたのでなるべく早く方針を決定したいと思います。-- ひげぽん
 -ちょっと今後のライブラリのあり方を整理させてください。~
 ~
 Monaはlibcなどにとらわれずソースを0から作成し新OSを作るのが理念だと理解しています。~
 ~
 また、Monapiはこれからも開発を続けて最終的には~
 どんなアプリ・ソフトでも作成できるようなある意味MFCにも相当するような巨大な~
 オールインワンライブラリになる必要があります。~
 ~
 この二つの事柄を合わせると、~
 すなわち遅かれ早かれlibc作成に匹敵するような労力がこの先~
 Monapiにつぎ込まれる必要が来ると言うことです。~
 ~
 わかりにくかったらすいません・・・(汗)~
 ~
 ~
 もう一度説明しなおしますと、~
  Mona、Monapiは0からでなくてはならない  +~
  Monapiはオールインワンで巨大でなければならない~
 =~
  オールインワンなMonapiを結局は0から構築する事になる。(この為の労力は絶対必要になる)~
 →オールインワンって事はMonapiからlibcをエミュレートできるのでは?~
 こんな感じでしょうか。~
 ~
 ~
 すいません。先日ではlibcをメンバーで作るべきだと書きましたがMonapiとの二度手間になると気づいてから考えが変わりました。(汗)~
 ~
 libcを作るのではなくその労力をMonapiに向けMonapiを0からしっかり構築し、~
 Monapiの中からlibcをエミュレートすべきではと言うのが今の私の考えです。~
 ~
 現在関数を作ろうと思えばそれをlibcに入れるべきかMonapiに入れるべきか迷うのはコードの無駄になりそうですので~
 今あるのもできるなら全部Monapiに吸収する形にしてしまって、統合した方がいいと思います。~
 ~
 例えば、strcpy()はMonapiの中でMonapi::String::Copy()みたいな今風の新しい形で書いて実装して、~
 過去互換のためのstring.hの中の関数strcpy()は{Monapi::String::Copy();}を呼び出すような・・・~
 現在ではMonapiとlibcの関数が交錯してMonapiの中からlibcを呼んだりその逆だったりしますが完全にMonapiをlibcの上(下?)におく形にします。~
 (もちろん必要ならmemcpyなどこれ以上簡単にできそうにもない関数はMonapiの中にそっくり取り込んでもいい。)~
 ~
 強力なMonapiを構築すれば(それはいずれ来る)理論的にはMonapiからlibcを作れるようになるはずですので~
 だったらnewlibは移植しなくてもよくなるようになるはずでは・・・・と思います。~
 ~
 長くなってしまってすいません。~
 しかしライブラリの大整理はいつかは必要になる物だと思いますので僭越ながら私の一案としてここに提案しておきます。~
 -- [[junjunn]] &new{2005-07-05 (火) 23:21:18};
 -ご意見ありがとうございます。こうやって比較していただくと、ゼロから作るのもありな気がしてきました。ただし以下の点が心配です。自分の経験不足でこのあたりが読みきれないですすいません。
 ++ libcを書き直すコスト(期間)はどれくらいか?(移植と比較して何倍くらい大変か?)
 ++ 上記関連して、現在のアクティブなメンバーでそれに取り組んだ場合に、どの程度かかるのか?-- [[ひげぽん]] &new{2005-07-05 (火) 18:38:54};
 -Monaは負の遺産を切り捨ててlibcにとらわれないって考えには賛成です。~
 しかし実際問題としては過去から現在(進行形で)まで
 ほとんどのC,C++で書かれたソースが何らかの形でlibcを使っているため
 膨大な既存の資産を生かすためにlibcの装備もまた必須かと。~
 ~
 --選択1.newlibなどから丸ごと移植
 ---○楽。
 ---○安定しているだろう。
 ---×不必要なコードが多く混じっていて綺麗とはいいがたい。
 ---×ライセンスがゴチャゴチャしてる。
 ~
 --選択2.メンバーで0から作る。(monalibc、またはlibcを標準ディレクトリとして誰でもどんどん追加)
 ---○自分たちで全てのコードを管理しているので融通が利く。
 ---○.cppで綺麗に書ける。(libcは完結してるのでメンテの必要あるかってのは別の話ですが・・)
 ---×手間がかかる。
 ---×手間の関係で全ての関数は実装できない。
 ---×安定するまでは少なからずバグが潜むだろう。
 
 個人的には後者派です。~
 別に全部は実装しなくても必要になった物をその時に書いて
 追加してゆくようにすれば十分手の届く範囲かと。~
 (現に今でもnewlibなくて動いているわけですし。)
 ~
 折衷案としてnewlibをとりあえず移植して環境を整えておいて
 自分たちで書いたソース部分はnewlibを上書きして採用してゆくのもありだと思いますが。
 [[junjunn]] &new{2005-07-05 (火) 12:07:13};
 
 -言葉足らずでした。libc移植をメインでやるのは厳しいですが、libc移植からいろいろと学ぼうという気はあります。 -- [[ひげぽん]] &new{2005-07-01 (金) 14:53:04};
 -monalibcは、サブ扱いでOKですよ。libcなんてものは、システムコールのラッパー+よく使う関数群みたいなものですし。移植とか堅苦しく考えず、使いたくなった関数があればそのときに追加していけばいいかなというのが個人的な感想です。 -- [[shadow]] &new{2005-07-01 (金) 10:46:29};
 -libcに取り組むことは「Monaの初志から外れる」そうですが、実際に実装するかどうかはともかく、libcの知識はUNIXやC言語を扱う上で基礎となる知識でMonaと関係なくても知らないでは済まされないことなので、まるで他人事のように避けてしまう姿勢はちょっとどうかと感じました。普段「まだまだ実力が足りないから勉強する」というような趣旨の発言をされているのに、一般的なプログラミング技術の基礎として重要な部分をオプショナルなものとして考えておられるのは、自分で自分の能力にリミッターを掛けているというか、ブレーキとアクセルを同時に踏んでいるような矛盾を感じました。ちょっときつくなりましたが、これは移植をやれと言っているわけではなく、姿勢というか認識の問題です。 --  &new{2005-07-01 (金) 01:49:27};
 -monacって何のことですか? --  &new{2005-07-01 (金) 01:04:30};
 -- monacapiに修正しました。 -- ひげぽん
 -もっとも現状のDLLはコードセグメントを共有していないのでメモリ的には無駄が多いですけどね。共有メモリと同じようにDLLもコードセグメントを共有できるようにしないと本当の節約にはなりません。 --  &new{2005-06-30 (木) 11:28:52};
 -サイズを小さくするために関数ごとに別クラスに分けることを希望します。 --  &new{2005-06-30 (木) 10:38:12};
 --スタティックリンクのことですか?クラス?ソースでなくて? --  &new{2005-06-30 (木) 10:41:11};
 --ごめんなさい。ソースですね・・。strcpy.cpp とかです。 --  &new{2005-06-30 (木) 11:05:08};
 --それであればDLL使えばいいやで分割はお流れになったはずです。→[[議論/ライブラリ/MonAPI整理]] --  &new{2005-06-30 (木) 11:14:49};
 -tmpmonalibcとmonalibcをマージ希望。monacapiはずっとこのままでいい気がします。 --  &new{2005-06-30 (木) 10:37:30};

リロード   新規 編集 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.057 sec.