https://developer.aliyun.com/article/774757os与语言的关系从来不是先有蛋还是先有鸡，而是先有蛋（语言），再有OS（鸡），自举语言和自举OS特殊情况另当别论，历史上和我们现实中出现过的常见OS，其kernel都是C开发的（我仅指osx,linux,windows kernel），，c runtime作为toolchain系统实现层面存在。c库存在用户空间和程序空间的部分是有特权不同的，它们之间要跨syscall互访。应用开发层次的语言系统处在用户空间(由此,官方py版本这种语言是不可能作内核编程的，抽象层次太高运行时也巨大)。我们把内核中的c称为“bearmetal或toolchain”语言，因为它们最开始的作用是给硬件平台提供软件管理层的作用。
由于语言放在OS之前设计（没办法，先得用起来，那个时候还没有出现既能保证开发效率运行效率又能保证安全的语言如rust），架构于os kernel之上。于是kernel的二大机制（内存管理和任务进程）会继承C语言的固有缺点，比如运行在这种OS上的程序会发生内存泄漏，这对于系统实现和APPDEV级都是延续的影响。我们现在的OS，如果它们自我宣称它们是“安全的OS”，其实是某些高阶层次的完全，比如OS应用方面的安全。并不是“内存管理和任务进程”方面的绝对安全。运行在这种OS上的APP还是会发生内存泄漏，因为“程序申请内存”这个功能，无论处在编程的哪个层次，都是从OS继承的能力（任何编程都是某种意义上的系统编程）。GC只是自动释放并不能改变OS内核这种可能的缺陷（这只是一种可能，OS内核的质量会保证这种情况很少出现）。
那么，为什么不采用一种从一开始就足够安全的bearmetal语言呢，如rust？
当然可以，语言放在OS之前设计可以直接省掉OS发明的很多问题，如cpu的保护模式甚至都可以略去，特权模式无关紧要，一种内核天然是bearmetal和usermode通用的（驱动和hal层放在用户空间）。你甚至还可以将rust的stdlib整个实现在bearmetal层,使得内核编程跟系统开发编程/系统应用编程共享同一门语言。
这些特点加起来，可以直接用语言作为虚拟机管理器（这种语言系统和OS最绝佳的关系，正是另一种os kernel-libos的特点：它可作为lib的os被嵌入语言使用，用户态无须经过虚拟机管理器。直接为支持“一app一os”而提出的os）。因为你可以把语言系统作为OS的源。直接compile and run一个kernel出来，使得语言架构于OS之上，做成devable os。在《云APP，virtual appliance：unikernel与微运行时的绝配,统一本地/分布式语言与开发设想》中我们提到unikernel是docker等lanauge runtime的代替品。这里是“more safer unikernel”。
--
FROM 117.147.21.*