カーネルのモード設定は、最初はLinuxに乗るのがちょっと大変でしたが、今ではとても素晴らしいです。つまり、Xはrootとして実行する必要はありませんか？高解像度ハードウェアアクセラレータコンソール？クール。
問題は、多くのUNIXプラットフォームにモード設定カーネルドライバーがないことです。したがって、KMSに依存するハードウェアは、現在Linuxに限定されています。
私の質問：なぜこれを実際にカーネルに実装するのですか？
画面解像度を設定するためにハードウェアアクセスが必要な場合は、別の特権デーモンまたは小さなsetuidバイナリを使用しないのはなぜですか。これにより、特権コードを分離し、表示サーバーを制限付きユーザーとして実行できるという利点が維持されます。特別なドライバ要件を取り除き、クロスUNIXサポートをより簡単にします。正しい？または私はここで重要な何かを見逃していますか？
それがマイクロカーネル OSアーキテクチャの背後にある考え方です。
—
Barmar 2015
この場合、マイクロカーネルタイプのモデルではなく、異種カーネル間の移植性について考えています。
—
DanL4096 2015
KMSはOpenBSDとFreeBSDでも使用されており、SolarisでもKMSが機能しています。このようにして、開発者がLinux用の動作するドライバーを作成すると、ドライバーサポートはKMSを使用する他のユーザーにも流れます。
—
hspaans 2015年
それは建築的なものです。ハードウェアアクセスは、カーネルのタスクの1つです。カーネルとユーザー空間の間で作業を分割するのは厄介です。実際にはぼやけたインターフェースで1つの作業のみを実行する2つのコンポーネントが必要になるためです。最終的には、カーネルのドメイン内で作業を実行することになるため、すべてをカーネルに入れる強いケースがあります。もちろん、ただし、どこにでも実装できます。堅牢なプラットフォームとは、明確に定義された（！）アーキテクチャとインターフェイスのことです。それはすべてぐらつきます。
—
Bananguin 2015年
さまざまな種類のクラッシュによりコンソールが奇妙なモードになり、Xが機能しなくなったかなり長い期間がありましたが、TTYスタイルのコンソールアクセスは実際には復元されませんでした。IIRC GLアクセラレーションの問題とクラッシュは、この状況を頻繁に引き起こしていました。KMSは、カーネルが問題を修正し、コンソールの状態を復元する方法を知っていることを意味します。IOWは一部ユーザビリティの改善です。カーネルがユーザースペースデーモンにこれを行うように要求できると主張する人もいるでしょうが、私はそれが常にうまくいくとは限らないと思います。また、カーネルに入れても、クローズドソースの問題は発生しません。
—
James Youngman、