为什么Linux内核需要15+百万行代码？ [关闭]

#1 楼

驱动程序被维护在内核中，因此当内核更改需要对功能的所有用户进行全局搜索和替换（或搜索并手动修改）时，更改人员将完成更改。由人们进行API更改来更新驱动程序是一个很好的优势，而不是当它没有在较新的内核上编译时不必自己动手。

替代方法（这是发生在驱动程序是在树外维护的），是补丁必须由其维护人员重新同步以跟上任何更改。

快速搜索引发了关于树内与.NET的争论。树外驱动程序开发。

Linux的维护方式主要是将所有内容保留在主线存储库中。 config选项支持控制#ifdef s的构建精简内核。因此，您绝对可以构建精简的精简内核，这些精简内核仅编译整个存储库中的一小部分代码。

嵌入式系统中Linux的广泛使用已导致更好地支持将内容遗漏掉。 Linux早于内核源代码树较小的年份。极小的4.0内核可能小于极小的2.4.0内核。

#2 楼

根据针对3.13运行的cloc，Linux大约有1200万行代码。


驱动程序中有700万个LOC / arch中的200万个LOC /仅139个我的Debian笔记本电脑上的内核中的上千个LOC /
lsmod | wc在运行时显示158个模块，因此动态加载模块是支持硬件的一种常用方法。系统（例如make menuconfig）用于选择要编译的代码（更重要的是，要编译的代码）。嵌入式系统仅使用它们关心的硬件支持（包括支持内置于内核或作为可加载模块的硬件）来定义自己的.config文件。

#3 楼

对于任何好奇的人，以下是GitHub镜像的线数细分：

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

drivers贡献了很多线数。

#4 楼

到目前为止，答案似乎是“是，有很多代码”，没有人用最合乎逻辑的答案来解决这个问题：1500万+？所以呢？ 1500万行源代码与鱼价有什么关系？是什么使它如此难以想象？

Linux显然做了很多事情。比什么都重要……但是，您的一些观点表明，在构建和使用它时，您不尊重正在发生的事情。内核构建系统使您可以快速定义选择源代码集的配置。有些是实验性的，有些是古老的，有些不是每个系统都需要的。在/boot/config-$(uname -r)中查看make menuconfig（在Ubuntu上），您将看到排除了多少。

这是目标可变的桌面发行版。嵌入式系统的配置只会提取所需的内容。


并非所有内容都是内置的。在我的配置中，大多数内核功能都是作为模块构建的：打印出来，制成一个巨大的纸三明治。除非您为离散的硬件工作进行自定义构建（在这种情况下，您已经限制了这些项目的数量），否则这将毫无意义。


模块是动态加载的。即使系统具有成千上万的可用模块，该系统也将允许您仅加载所需的内容。比较以下内容的输出：

grep -c '=m' /boot/config-`uname -r`  # 4078
grep -c '=y' /boot/config-`uname -r`  # 1944

几乎没有加载任何内容。


微内核不是一回事。只需10秒钟，便可以查看链接到Wikipedia页面的主要图像，以突出显示它们的设计完全不同。



Linux驱动程序是内部化的（大部分是动态加载的模块），而不是用户空间，并且文件系统类似地是内部的。为什么这比使用外部驱动程序更糟糕？为什么Micro更适合用于通用计算？



这些评论再次强调您无法理解。如果要在离散硬件（例如航空航天，TiVo，平板电脑等）上部署Linux，则可以将其配置为仅构建所需的驱动程序。您可以使用make localmodconfig在桌面上执行相同的操作。最后，您得到的是一个微型的，针对目的的内核构建，灵活性为零。

对于像Ubuntu这样的发行版，可以使用一个40MB的内核软件包。不，要解决这一问题，实际上，与将归档包保持4000多个浮动模块的大规模归档和下载方案相比，这实际上是更可取的。它为他们使用更少的磁盘空间，在编译时更易于打包，更易于存储，并且对他们的用户（拥有一个可以正常工作的系统）更好。（br />）还是一个问题。 CPU速度，磁盘密度/定价和带宽改进的速度似乎比内核的增长快得多。十年之内，一个200MB的内核软件包将不会终结。

这也不是一条路。如果不进行维护，代码确实会被踢出。

#5 楼

tinyconfig气泡图svg（小提琴）

shell脚本从内核构建创建json，与http://bl.ocks.org/mbostock/4063269一起使用


编辑：原来unifdef有一些限制（-I被忽略，-include不被支持，后者用于包含生成的配置头），此时使用cat并没有太大变化：

274692 total # (was 274686)

脚本和过程已更新。


除了驱动程序，arch等外，根据选择的配置，是否编译了很多条件代码，代码不一定在动态加载的模块中，而是内置在内核中。

因此，下载了linux-4.1.6的源代码，选择了tinyconfig，它没有启用模块，老实说我不知道它启用或用户可以在运行时使用它做什么，无论如何，请配置内核：

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

构建内核

time make V=1 # (should be fast)
#1049168 ./vmlinux (I'm using x86-32 on other arch the size may be different)

内核构建过程将隐藏f使用命令行也称为*.cmd的文件，还用于构建.o文件，处理这些文件并提取目标文件和依赖项，并将其复制到下面的script.sh中，并与find配合使用：

find -name "*.cmd" -exec sh script.sh "{}" \;

为目标.o的每个依赖项创建一个副本，名为.o.c

.c代码

find -name "*.o.c" | grep -v "/scripts/" | xargs wc -l | sort -n
...
   8285 ./kernel/sched/fair.o.c
   8381 ./kernel/sched/core.o.c
   9083 ./kernel/events/core.o.c
 274692 total

make headers_install INSTALL_HDR_PATH=/tmp/test-hdr
find /tmp/test-hdr/ -name "*.h" | xargs wc -l
...
  1401 /tmp/test-hdr/include/linux/ethtool.h
  2195 /tmp/test-hdr/include/linux/videodev2.h
  4588 /tmp/test-hdr/include/linux/nl80211.h
112445 total

#6 楼

Tananbaum和Torvalds从一开始就在公众中讨论了整体内核的权衡问题。如果您不需要所有内容都进入用户空间，那么与内核的接口可以更简单。如果内核是单片的，则可以在内部对其进行优化（并且更加混乱！）。

我们已经有一段时间作为折衷方案了。而且它还在继续进行DPDK之类的工作（将更多的网络功能移出内核）。添加的核心越多，避免锁定就越重要。因此更多的东西将进入用户空间，内核也会缩小。

请注意，单片内核不是唯一的解决方案。在某些体系结构上，内核/用户空间边界并不比任何其他函数调用都要昂贵，这使得微内核具有吸引力。