关于操作系统自然的做法：凡是为进程服务的模块就应放在操作系统的内核中。例如：文件管理模块是为进程服务的，所以应放在内核中；设各驱动模块是为进程服务的，所以要放在内核中；进程管理模块当然也要放在内核中。随着进程对服务需求的增加，操作系统的内核就越来越大，随之也出现了一系列问题。
首先，由于内核是常驻内存的，因此大内核占用的存储空间就大，这样在硬件系统比较小，存储器资源比较紧张的系统中就不太适用；其次，是维护起来也比较困难，假如内核中的某一个服务模块进行了修改，那么在修改之后就必须对整个系统进行一次编译，显得极不方便；再次，就是使得处理器在内核运行的时间变长，从而不适合在速度要求较高的场合下应用。
总之，操作系统的内核大到一定程度之后，会出现一系列因为大而产生的诸多问题。为了解决这些问题，人们想了一系列的办法试图在满足应用程序所需服务的前提下把内核做小。其中一个有效的办法是，把内核各个服务程序模块中的部分内容移到内核的外面作为一个进程来看待，在内核中只保留内核服务与用户进程的接口，或者说只保留一个“壳”。在用户进程需要该服务时，由这个“壳”通过发送消息的方法与服务进程进行联系，当与这个服务相关的服务进程接收到这个信息时就马上启动这个服务。这样，内核中保留的只是一些服务模块的“壳”．或耆说是消息的转送站，于是内核就可以大大变小了。这种内核就叫做“微内核”，具有微内核的操作系统叫做微内核操作系统。
因此,在操作系统内核的设计上有两种结构：宏内核结构和微内核结构。
宏内核的内部可被分为若干模块（或者是层次或其他）。但是在运行时，它是一个独立的二进制大映像。模块间的通信不是通过消息传递，而是通过直接调用其他模块中的函数来实现的。
在微内核中，用以完成系统调用功能的程序模块通常只进行简短的处理，而把其余工作通过消息传递交给内核之外的进程来处理。在典型情况下，每个系统调用程序模块都有一个与之对应的进程，微内核部分经常只不过是一个消息转发站，这种方式有助于实现模块间的隔离。这种内核设计的最根本思想就是要保持操作系统的内核尽可能小，因为内核是直接与计算机硬件相关的，内核越小，就越便于在不同的硬件系统间进行移植。微内核结构的另外一个优点是，可以使不需要的模块不加载到内存中，因此，微内核就可以更有效地利用内存。
微内核和宏内核的例子都非常好找。我们一直拿在手边的Minix，以及每天在用的Linux，便是两者的典型例子。Minix是微内核的，Linux则是宏内核的。
说起这两个例子，有一段轶事不能不提。那就是当年Tanenbaum和Linus一老一少的口舌之争。话说Linus写了个操作系统叫做Linux，使用的是宏内核，他把这个消息发在了comp.os.minix新闻组上，这时Tanenbaum说话了，把Linux批评了一通，年轻气盛的Linus于是发信回击，这样一来二去，为我们留下一段微内核与宏内核的经典争论。
争论的全部内容在这里我们就不全部转述了，读者感兴趣的话可以用搜索引擎很容易地搜到（或者在维基百科上看一下），我们把其中的重点说一下。
Andy(Andrew S.
Tanenbaum):
老一点的操作系统都是宏内核的，也就是说，整个操作系统是一个运行在核心态的单独的a.out文件，这个二进制文件包含进程管理、内存管理、文件系统以及其他。具体实例包括UNIX、MS-DOS、 VMS、MVS、OS/360、MULTICS等。
另一种便是微内核，在这种系统中操作系统的大部分都运行在单独的进程，而且多数在内核之外。它们之间通过消息传递来通信。内核的任务是处理消息传递、中断处理、底层的进程管理，以及可能的I/O。这种设计的实例有RC4000、Amoeba、Chorus、Mach，以及还没有发布的Windows/NT。
我完全可以（但不必）再讲述一段关于两者之间相对优势的很长的故事，然而在实际设计操作系统的人中间说说就够了，争论实际上已经结束。微内核已经取得了胜利。对于宏内核而言唯一的争论焦点在于效率，不过已经有足够的证据表明微内核可以像宏内核一样快（比如Rick Rashid已经发表了Mach 3.0和宏内核系统的比较报告）所以那不过是喊喊而已罢了。
Minix是微内核的，文件系统和内存管理是单独的进程，它们运行在内核之外。I/O驱动也是单独的进程（在内核之内，但仅仅是因为Intel CPU的糟糕设计使得很难不这样做）。Linux是个宏内核的系统。这相当于向七十年代倒退了一大步。就好比将一个已存在的工作得很好的C程序用Basic重写一遍。在我看来，在1991年写一个宏内核的系统真不是个好主意。”
以上前两段基本上可以被认为是宏内核和微内核的基本概念。从概念上我们不难猜到，宏内核看上去试图包办一切，而微内核恰恰相反，它的任务只是“处理消息传递、中断处理、底层的进程管理，以及可能的I/O”，而其他事情都交给内核之外单独的进程来完成。
在这段文字中Andy不但阐述了宏内核和微内核的概念，摆明了对于这个问题鲜明的观点，而且他也毫不掩饰自己对宏内核的不屑。而且这种不屑让他认为Linux简直是技术的倒退。在随后的文字中，对于Linux的可移植性Andy也做了不客气的批评。也难怪Linus对此非常恼火。从Linus的第一个回复开始，这场争论开始变得精彩起来。
Linus：
好吧，既然是这么一个主题，我恐怕不能不做回答了。向已经听了太多关于Linux的Minix使用者们道歉。我很乐意上钩（Andy说了这些话，好像在引诱Linus开始一场争论——笔者注），该是吵一架的时候了！
是的，Linux是宏内核，我同意微内核更好些。如果不是你使用了具有争论性的主题，我可能会同意你大部分的观点。从理论上（以及美学上）讲Linux是输了。如果去年春天GNU内核已经做好，我可能不会这么麻烦地开始我的工作：问题是它没有做好而且到现在都没有。在已经实现这一方面Linux赢大了。
Minix是微内核系统……Linux则是宏内核的。如果这是评价内核好坏的唯一标准，那么你是对的。你没有提到的是Minix的微内核实现得并不好，而且（内核内）多任务存在问题。如果我做一个多线程文件系统存在问题的操作系统，我可能不会这么快就声讨别人：事实上我会尽最大努力让别人忘掉我的失败。
这一段我觉得非常重要，因为看得出来，Linus内心还是承认微内核的优势的，而且他提到了“美学”（aesthetical）这个词，因为的确，微内核的思想更加优雅，这在我们下文中的分析中也可以看到。不过尽管如此，他还是批评了Minix本身，认为它的微内核实现的并不令人满意。
在后来谈到可移植性的时候，Linus的话也颇具初生牛犊不怕虎的劲头：
可移植性是为不能编写新程序的人设计的
——我，现在（使用傲慢的语气）
对于从技术实现的角度来看,Linus无疑是对的,对于底层技术抱有棱角分明的态度的意义远远大于Tanenbaum基于扩展开发的实用主义的态度的意义。