DNIX

DNIX (元の綴り: D-Nix )は、スウェーデンの会社Dataindustrier AB (DIAB) が開発した、現在は製造中止となっているUnix ライクな リアルタイム オペレーティング システムです。ABCenix というバージョンは、Luxor のABC 1600コンピュータ用に開発されました。Daisy Systemsも、一部のコンピュータ支援設計(CAD)ワークステーションに Daisy DNIX というシステムを搭載していました。これは DIAB の製品とは無関係です。

Dataindustrier AB (直訳: コンピュータ産業株式会社) は、1970 年に Lars Karlsson によってスウェーデンのスンツヴァルでシングルボードコンピュータ製造会社として設立され、Data Board 4680というZilog Z80ベースのコンピュータを製造しました。^{[説明が必要] 1978 年、DIAB はスウェーデンのテレビ会社}Luxor ABと提携して、家庭用およびオフィス用のコンピュータシリーズABC 80およびABC 800の製造を開始しました。

1983年、DIABはモトローラ68000 CPUをベースにした初のUnix互換マシン、DIAB DS90を独自に開発した。ここでAT&T CorporationのUNIX System VライセンスをベースにしたD-NIXが登場した。しかしDIABは産業用制御システム（オートメーション）企業であり、リアルタイムオペレーティングシステムを必要としていたため、AT&T提供のUNIXカーネルを自社開発の互換性のあるリアルタイム版に置き換えた。このカーネルは、Litton IndustriesのMonroe Systems部門向けに作成されたOS.8というZ80カーネルにヒントを得たものである。^{[1] [2]}

DIABは時が経つにつれ、UNIX標準のユーザースペースツールのいくつかを自社の実装に置き換え、UNIX由来のコードが一切存在しなくなり、AT&T UNIXライセンスに依存せずにマシンを展開できるようになった。2年後、Luxorと共同でABC 1600というコンピュータがオフィス市場向けに開発され、同時にDIABはMotorola 68010、68020、68030、そして最終的には68040といったMotorola CPUの新しいバージョンを使用したDS90コンピュータの拡張バージョンを生産し続けた。1990年にDIABはGroupe Bullに買収され、同社は引き続きDIABのブランド名でDSマシンを生産・サポートし、 DIAB 2320、DIAB 2340などの名前で販売し、依然としてDIABバージョンのDNIXを実行していた。^[3 ]

ISC Systems Corporation (ISC) は、1980 年代後半にMotorola 68kベースの銀行用コンピュータのラインで使用するために DNIX を使用する権利を購入しました。(ISC は後にOlivettiに買収され、次にWangに再販され、Wang はその後Getronicsに買収されました。この企業体は、ほとんどの場合「ISC」と呼ばれ、長年にわたって混乱を招くほど多くの名前で呼ばれてきました。) このコード ブランチはSVR2互換バージョンであり、ISC の手によって広範囲にわたる変更と開発が行われました。このオペレーティング システムの注目すべき機能は、デマンドページング、ディスクレスワークステーション、マルチプロセッシング、非同期 入出力(I/O)、ファイル システム内のディレクトリにプロセス (ハンドラ) をマウントする機能、およびメッセージ パッシングのサポートでした。リアルタイムサポートは、主にリスト検索メカニズムではなく内部イベント駆動型キュー (「大群の群れ」なし^[4] )、2 つのクラスの静的プロセス優先度 (完了まで実行とタイムスライス)、連続ファイルのサポート (重要なリソースの断片化を避けるため)、およびメモリロックで構成されていました。直交非同期イベント実装の品質は、現在の商用オペレーティングシステムではまだ匹敵するものがありませんが、いくつかはそれに近づいています。 (まだ採用されていない概念は、すべての非同期アクティビティの同期マーシャリングポイントも、無限に非同期にできるということです。DNIX はこれを堂々と処理しました。)非同期 I/O機能により、 Berkeley ソケット 選択またはSVR4のSTREAMS ポーリングメカニズムが不要になりましたが、下位互換性のためにソケットセマンティクスを保持するソケットエミュレーションライブラリがありました。DNIX のもう 1 つの特徴は、標準ユーティリティ (頻繁に問題となるpsなど) が、ジョブを実行するためにカーネルのメモリ内を探し回らないことです。代わりにシステムコールが使用され、これによりカーネルの内部アーキテクチャは必要に応じて自由に変更できるようになりました。ハンドラの概念により、ネットワークプロトコルスタックをカーネルの外部に置くことができるため、開発が大幅に容易になり、全体的な信頼性が向上しましたが、パフォーマンスは低下しました。また、外部ファイルシステムをユーザーレベルのプロセスにすることもでき、これも信頼性の向上につながりました。メインファイルシステムは、外部プロセスになる可能性がありましたが（かつてはそうでした）、パフォーマンス上の理由からカーネルに取り込まれました。これがなければ、DNIX はマイクロカーネルですが、正式にはそのように開発されたわけではありません。ハンドラは、任意のタイプの「ネイティブ」 Unix ファイル、ディレクトリ構造、またはデバイスとして表示され、ハンドラが処理できないファイル I/O 要求は、ハンドラがマウントされている基になるハンドラを含む他のハンドラに渡すことができます。ハンドラ接続も存在し、パイプのようにファイル システムとは独立して渡されます。この効果の 1 つは、カーネルベースの疑似端末機能 を必要とせずに、テキスト端末(TTY) のようなデバイスをエミュレートできることです。

ハンドラが役に立った例として、ISC のディスクレス ワークステーション サポートが挙げられます。このサポートでは、実装のバグにより、ワークステーションで名前付きパイプを使用すると、ファイル サーバーで望ましくないリソース ロックが発生する可能性がありました。適切なカーネル修正が開発されるまで、問題のある名前付きパイプへのアクセスを処理するハンドラがワークステーション上に作成されました。このハンドラを実装するには約 5キロバイトのコードが必要でした。これは、重要なハンドラはそれほど大きくする必要がないことを示しています。

ISC は、 DIABの DS90-10 および DS90-20 マシンをファイル サーバーとして製造する権利も取得しました。しかし、マルチプロセッサの DS90-20 は対象市場にとって高価すぎたため、ISC は独自のサーバーを設計し、DNIX をそれらに移植しました。ISC は、これらのファイル サーバーで使用するために独自のGUIベースのディスクレス ワークステーションを設計し、DNIX を再度移植しました。(ISC は、DIAB の DNIX を実行するマシンの設計に Daisy DNIX を実行する Daisy ワークステーションを使用しましたが、製図およびレイアウト スタッフがソフトウェア スタッフとほとんど話をしなかったため、社内で混乱はほとんどありませんでした。さらに、ハードウェア設計スタッフはどちらのシステムも使用していませんでした。よく言われるジョークは、「ISC ではコンピューターは構築しますが、使用しません」というものでした。) DNIX の非同期 I/O サポートにより、ワークステーションでイベント駆動プログラミングを簡単に実行でき、比較的限られたリソースにもかかわらず、ワークステーションは優れたパフォーマンスを発揮しました。 (GUI ディスクレス ワークステーションには 7 MHz の68010プロセッサが搭載されており、512K のメモリで使用可能で、その約半分をカーネルが消費しました。ほとんどのワークステーションのメモリは 1 MBでしたが、後に 2 MB および 4 MB のバージョンや 10 MHz プロセッサが登場しました。) 本格的なインストールは、1 台のサーバー (16 MHz の68020、8 MB の RAM、200 MB のハード ディスク) と最大 64 台のワークステーションで構成できます。起動は遅いものの、このようなアレイは銀行の出納係アプリケーションでは十分なパフォーマンスを発揮します。DNIX 本来の効率性に加えて、関連するDIAB C コンパイラが高性能の鍵となりました。特に ISC が使用した後、68010用の優れたコードを生成しました。 (ISC は、これを、最新のワークステーションで使用されていたTexas Instruments TMS34010グラフィックス コプロセッサに再ターゲットしました。) DIAB C コンパイラは、もちろん、DNIX の構築に使用されました。これは、DNIX の効率性に貢献する要因の 1 つであり、Wind River Systemsを通じて何らかの形で今でも入手可能です。

これらのシステムは、2006 年に本稿を執筆した時点でも、現在Bank of America というブランド名になっている旧Seattle-First National Bank の支店で使用されています。他の ISC 顧客も、何らかの形で DNIX をまだ使用している可能性があります。ISC を通じて、中南米では DNIX がかなり普及していました。

DNIX のネイティブ システム コールはdnix(2)ライブラリ関数で、標準の Unixunix(2)またはsyscall(2)関数に似ています。複数の引数を取り、最初の引数は関数コードです。意味的には、この単一の呼び出しで適切な Unix 機能がすべて提供されますが、構文的には Unix とは異なり、もちろん DNIX 専用の拡張機能も多数あります。

DNIX 機能コードは、タイプ 1 とタイプ 2 の 2つのクラスに分類されました。タイプ 1 コマンドは、I/O アクティビティに関連付けられたもの、または発行プロセスのブロックを引き起こす可能性のあるものです。主な例としては、、、、、、、、、などがあります。タイプF_OPEN2は、、、などの残りのものです。これらはカーネルによってすぐに満たされる可能性があります F_CLOSE。F_READF_WRITEF_IOCRF_IOCWF_WAITF_NAPF_GETPIDF_GETTIME

非同期を呼び出すには、タイプ 2 オペコード を介して、トラップ キューと呼ばれる特別なファイル記述子F_OTQを作成する必要があります。タイプ 1 呼び出しでは、F_NOWAITビットがその関数値と OR 演算され、 への追加パラメータの 1 つがdnix(2)トラップ キュー ファイル記述子になります。非同期呼び出しからの戻り値は、通常の値ではなく、カーネルが割り当てた識別子です。非同期要求が完了すると、トラップ キュー ファイル記述子の 、read(2)(または 、F_READ) は、識別子と結果ステータスを含む小さなカーネル定義の構造体を返します。 、F_CANCEL操作は、まだ完了していない非同期操作をキャンセルするために使用でき、その引数の 1 つはカーネルが割り当てた識別子でした。 (プロセスは、現在自己所有されている要求のみをキャンセルできます。キャンセルの正確なセマンティクスは、各要求のハンドラによって異なり、基本的には待機が終了することを意味します。部分的に完了した操作を返すことができます。) カーネルが割り当てた識別子に加えて、非同期操作に渡される引数の 1 つは、32 ビットのユーザー割り当て識別子でした。これは、ほとんどの場合、I/O 完了メソッドを処理する適切なサブルーチンへの関数ポインタを参照しますが、これは単なる慣例です。この値を解釈する責任があるのは、トラップ キュー要素を読み取るエンティティです。

struct itrq { /* トラップ キューから読み取られたデータの構造体。 */ short it_stat ; /* ステータス */ short it_rn ; /* 要求番号 */ long it_oid ; /* 要求時に指定された所有者 ID */ long it_rpar ; /* 返されたパラメーター */ };                     
                   
                     
                     
                    

注目すべきは、非同期イベントが通常のファイル記述子読み取り操作によって収集され、そのような読み取りも非同期に実行できることです。これは、1 つのプロセス内に存在できる半自律的な非同期イベント処理パッケージに影響を及ぼしました (DNIX 5.2 には軽量プロセスやスレッドはありませんでした)。また、潜在的にブロッキングする可能性のある操作は非同期に発行できるため、DNIX は単一のサーバー プロセスで多数のクライアントを処理するのに十分な機能を備えていることも注目に値します。プロセスは 1 つのトラップ キューだけを持つように制限されていなかったため、このようにして I/O 要求を大まかに優先順位付けできました。

ネイティブ呼び出しに加えて、完全な「標準」 libcインターフェイス呼び出し dnix(2)のセットが利用可能でした。 、、、、など。これらは下位互換性のために役立つだけでなく、 NCR Towerコンピュータとバイナリ互換な方法で実装されているため、このコンピュータ用にコンパイルされたバイナリは DNIX で変更せずに実行できます。DNIX カーネルには内部的に 2 つのトラップ ディスパッチャがあり、1 つは DNIX 方式用、もう 1 つは Unix 方式用です。ディスパッチャの選択はプログラマに任されており、両方を交換して使用することは許容されていました。機能が重複している場所では、意味的には同一でした。(これらのマシンでは、呼び出しには68000命令が使用され、 には 命令が使用されました。2 つのトラップ ハンドラは非常によく似ていますが、[通常は非表示の]呼び出しでは関数コードがプロセッサの D0 レジスタに保持されるのに対し、 では関数コードが残りのパラメータとともにスタックに保持されます。) open(2)close(2)read(2)write(2) trap #0unix(2)trap #4dnix(2)unix(2)dnix(2)

DNIX 5.2 には内部的にネットワーク プロトコル スタックがありませんでした ( ISC がディスクレス ワークステーション サポート パッケージで使用するために追加した薄いX.25ベースのEthernet プロトコル スタックを除く)。すべてのネットワークはハンドラへの読み取りと書き込みによって実行されました。したがって、ソケットメカニズムはありませんでしたが、libsocket(3)TCP/IP ハンドラと通信するために非同期 I/O を使用するものがありました。典型的な Berkeley 由来のネットワーク プログラムは、コンパイルして変更せずに実行できました (通常の Unix移植の問題を除く)。ただし、ネイティブの非同期 I/O を使用する同等のプログラムほど効率的ではない可能性があります。

DNIX では、プロセスを使用して I/O 要求を処理し、ファイル システムを拡張できました。このようなプロセスは ハンドラ と呼ばれ、オペレーティング システムの主要な機能でした。ハンドラは、少なくとも 1 つの要求キュー をF_ORQ所有するプロセスとして定義されました。要求キューは、または呼び出しのいずれかの方法で取得される特別なファイル記述子ですF_MOUNT。前者は、分離された要求キューを発明し、その一方の端は通常、子プロセスに渡されました。(多数あったネットワーク リモート実行プログラムは、この方法を使用して、子に標準の I/O パスを提供しました。) 後者はファイル システムにフックし、ファイル I/O 要求をハンドラが採用できるようにしました。 (ネットワーク ログイン プログラム (さらに多数) は、この方法を使用して子プロセスに標準 I/O パスを提供しました。これは、Unix でのログインのセマンティクスでは、おそらく無関係な複数のプロセスがオペレータへの標準 I/O パスに割り込む方法が必要であるためです。) ファイル システム内のディレクトリにマウントされると、ハンドラはその時点までのすべての I/O 呼び出しを受け取ります。

次に、ハンドラは、カーネルが割り当てた小さな要求データ構造を要求キューから読み取ります。(このような読み取りは、ハンドラの作成者の希望に応じて、同期または非同期で実行できます。) 次に、ハンドラは、各要求を満たすために必要なことすべてを実行します。多くの場合、DNIXF_UREADとF_UWRITE呼び出しを使用して、要求のデータ領域を読み書きし、を使用して要求を適切に終了しますF_TERMIN。特権ハンドラは、呼び出しを介して、下位ハンドラ (ファイル システムなど) への個々の要求に対するクライアントの権限を採用できるF_T1REQため、下位の権限スキームを再現する必要はありません。ハンドラが単独で要求を完了できない場合は、F_PASSRQ関数を使用して、あるハンドラから別のハンドラに I/O 要求を渡すことができます。ハンドラは、要求された作業の一部を実行してから、残りを別のハンドラに渡すことができます。ハンドラがステート マシン指向であることは非常に一般的で、クライアントから処理する要求はすべて非同期で行われます。これにより、単一のハンドラが複数のクライアントからの要求を同時に処理でき、クライアントが不必要にブロックされることはありません。リクエスト構造の一部にはプロセス ID とその優先度が含まれていたため、ハンドラーはこの情報に基づいて最初に作業するものを選択でき、作業はリクエストされた順序で実行する必要はありませんでした。これを支援するために、リクエスト キューとトラップ キューの両方をポーリングして、実際に作業を開始する前に検討すべき作業がまだあるかどうかを確認することができました。

struct ireq { /* 着信要求の構造 */ short ir_fc ; /* 機能コード */ short ir_rn ; /* 要求番号 */ long ir_opid ; /* オープンまたはマウント時に指定した所有者 ID */ long ir_bc ; /* バイト数 */ long ir_upar ; /* ユーザー パラメーター */ long ir_rad ; /* ランダム アドレス */ ushort ir_uid ; /* ユーザー ID */ ushort ir_gid ; /* ユーザー グループ */ time_t ir_time ; /* 要求時間 */ ulong ir_nph ; ulong ir_npl ; /* ノードおよびプロセス ID */ };                     
                     
                     
                    
                      
                    
                     
                   
                   
                  
           
                    

プロセスが持つことができるリクエスト キューの数には特に制限はありませんでした。これは、たとえば chroot jail にネットワーク機能を提供するために使用されました。

ハンドラーの有用性について少し説明すると、ISC では次のようなハンドラーが存在していました。

• 外部ファイルシステム
  • 脂肪
  • CD-ROM / ISO9660
  • ディスクイメージファイル
  • RAM ディスク (書き込み保護されたブート ディスクで使用)
• ネットワークプロトコル
  • DNET (基本的にはマルチキャスト機能を備えたイーサネット経由のX.25 )
  • X.25
  • プロトコル
  • 12 月の 緯度
  • アップルトーク
• リモートファイルシステム
  • DNETの /net/machine/path/from/its/root...
  • NFS
• リモートログイン
  • ncu ( DNET )
  • テルネット
  • rログイン
  • wcu ( DNET GUI)
  • X.25 パッド
  • 12 月の 緯度
• リモート実行
  • rx ( DNET )
  • レムシュ
  • レックス
• システム拡張
  • ウィンドウマン (GUI)
  • vterm ( xtermのような)
  • 書類（通帳）プリンター
  • dmap (ラプティムアナログ)
  • windowmac (Macintosh への GUI ゲートウェイ)
• システムパッチ
  • 名前付きパイプ ハンドラー

ISC は、DNIX の 5.2 ( SVR2互換) と 5.3 ( SVR3互換) の両方のバージョンを購入しました。購入当時、DNIX 5.3 はまだDIABで開発中だったため、導入されたのは DNIX 5.2 でした。時間が経つにつれて、ISC のエンジニアは 5.3 カーネルの機能のほとんど (主に共有メモリとIPC)を 5.2 に組み込んだため、 DIABと ISC の DNIX バージョンには機能の相違がありました。DIAB の 5.3 には、ISC の 5.2 よりも多くの SVR3 機能が含まれるようになったと思われます。また、DIAB はSVR4互換 OS である DNIX 5.4 に移行しました。

ISC では、開発者は自らのニーズと Unix 業界の一般的な傾向に基づいて、 DNIX 5.2 のバージョンを大幅に拡張しました (カーネルに関連する機能のみをリストしています)。

• ディスクレス ワークステーションのサポート。ワークステーションのカーネル ファイル システムは削除され、X.25 ベースの Ethernet 通信スタブに置き換えられました。ファイル サーバーのカーネルも拡張され、リモート要求を受信して​​カーネル プロセスのプールに渡して処理するマッチング コンポーネントが追加されましたが、これを行うための標準ハンドラーを作成することもできました。(製品ライフサイクルの後半で、ISC はDNIX サーバーの代わりに標準のSVR4ベースの Unix サーバーを導入しました。これらはX.25 STREAMSとカスタム記述のファイル サーバー プログラムを使用しました。構造化の効率は低かったものの、使用されたプラットフォームの純粋な処理能力により、はるかに高速なサーバーが実現しました。このファイル サーバー プログラムがネイティブ DNIX サーバーのすべての機能をサポートしていなかったのは残念です。名前付きパイプなどの扱いにくい機能はまったく機能しませんでした。これが、名前付きパイプ ハンドラー プロセスのもう 1 つの理由でした。)
• ISC のMMUの機能を使用したgdbウォッチポイントのサポート。
• ファイル システムへの非同期 I/Oが実現されました。(元々はとにかくブロックされていました。) これを行うためにカーネル プロセス (kproc またはスレッド) が使用されました。
• truss またはstraceのようなプログラムのサポート。標準の Unix ptraceシングルステップ メカニズムのバグの修正に加えて、トレーサーが既存のプロセスで標準のシングルステップ メカニズムを使用できるように、一時的なプロセス採用機能を追加する必要がありました。
• SVR4 シグナルメカニズムの拡張。主に新しいSTOPおよびCONTシグナル用ですが、新しいシグナル制御呼び出しも網羅しています。ISC のadbおよび sdb デバッガーのソース コードが不足しているため、u ページを変更できず、新しいシグナルはブロックされるか、デフォルトの処理を受けることしかできず、キャッチできませんでした。
• ネットワークスニッフィングのサポート。これには、単一のイベントが複数の I/O 要求を満たすことができるようにイーサネット ドライバーを拡張し、プロミスキャス モードをサポートするためにソフトウェアで条件付きでハードウェア フィルタリングを実装する必要がありました。
• ディスク ミラーリング。これはデバイス ドライバーではなくファイル システムで実行されるため、わずかに (または完全に) 異なるデバイスをミラーリングできます。フロッピーを取り出すとディスク エラーが発生しやすいため、小さなハード ディスクをフロッピーにミラーリングすることは、ミラーリングをテストする一般的な方法でした。
• 32 ビットのinode、30 文字のファイル名、シンボリック リンク、およびスティッキーディレクトリ拡張子がファイル システムに追加されました。/dev/zero、/dev/noise、/dev/stdXXX、および /dev/fd/X デバイスが追加されました。
• プロセス グループ ID リスト ( SVR4から)。
• #! スクリプトを直接実行します。
• ISC のZ-80ベースのVMEbus通信ボードを使用したシリアル ポートの乗算。
• 移動可能なスワップ パーティション。
• 実行中のプロセスのコア'dump' スナップショット。fuser コマンドのサポート。
• プロセス renice 機能。浮動優先度を実装するための関連するタイムシェアリング再優先順位付けプログラム。
• プロセスを「強奪」して、すべてのメモリ リソースを瞬時に奪う方法。まだ使用可能だが必ずしも使用されていないものとは異なり、現在のワーキング セットが何であるかを判断するのに非常に便利です。これは、プロセスのメモリ マップの 1024 ページすべてのステータスを表示する GUI ユーティリティに関連付けられていました。(これは、ISC の MMU でサポートされているメモリ ページの数です。) 使用時には、対象プロセスをその存続期間中に定期的に「強奪」し、スワップバックされたメモリの量を確認します。これは、ISC の実稼働環境では存続期間の長いプロセスが少数しか使用されなかったため、メモリの使用率と増加を制御することがパフォーマンス維持の鍵となり、便利でした。

1997 年に ISC での DNIX 開発が事実上終了したとき、計画されていた OS 機能のいくつかは未完成のまま残されました。

• 共有オブジェクト- 動的にロードされるライブラリが 2 つ存在していました。DNET の暗号化ライブラリと GUI のイメージング ライブラリです。ただし、この機能は一般化されませんでした。ISC のマシンは、一般的に仮想アドレス空間が不足していたため、メモリ マップされたエンティティを広範に使用することは不可能でした。
• 軽量プロセス–カーネルにはすでに単一の MMU コンテキストを共有する複数のスレッドがあったため、これをユーザー プロセスに拡張するのは簡単なはずでした。APIへの影響が最も難しい部分でした。
• アクセス制御リスト(ACL) – 標準のファイル システムにマウントされた ACL ハンドラーを使用して簡単に実装できます。
• 複数のスワップ パーティション – DNIX は、選択されたボリュームの空き領域をすでにスワップに使用しているため、次のボリュームに移動する前にボリュームの空き領域をすべて消費しないように、関連する領域制限とともに、順番に試すボリュームのリストを提供することは簡単だったでしょう。
• gdbによるリモート カーネル デバッグ- 通常のシリアル ポート経由、またはカーネルに組み込まれた X.25 リンク ソフトウェアを使用したイーサネット経由でデバッグを実行するためのすべての要素が揃っていましたが、それらは組み立てられませんでした。
• 68030 のサポート – ISC のプロトタイプは完成しませんでした。プロセッサ ピギーバック プラグイン カードが 2 枚作成されましたが、より高速な 68020 としてしか使用されませんでした。信頼性が低く、68020 ソケットに収まる必要があったため、本来の速度を発揮できませんでした。高速コンテキスト スイッチング ISC MMU は無効のまま (提案された生産ユニットでは完全に省略)、代わりに 68030 の組み込み MMU が使用され、DS90-20 の MMU コードの派生が使用されることになりました。ISC MMU は非常に効率的で、32 の常駐プロセス間での瞬時の切り替えをサポートしていましたが、アドレス指定能力が非常に限られていました。68030 MMU は、ISC MMU の限界である 8 MB をはるかに超える仮想空間をプロセスに使用できました。この MMU は低速になりますが、68030 の全体的な高速化により、それを補って余りあるはずであり、68030 マシンはあらゆる点でより高速になり、はるかに大規模なプロセスをサポートすることが期待されていました。

• リアルタイムオペレーティングシステムの比較
• オペレーティングシステムのタイムライン
• クロメンコ クロミックス