[25％OT] C库OS /内核的组成部分??? [英] [25% OT] C library integral part of OS/kernel???

问题描述

大多数操作系统的C库（即unix类型操作系统）是在

非常低的内核还是在内核级别之外实现的？


寻找通过Linux / BSD的源代码树，似乎C / $
库与操作系统交织在一起（string.h和其他标题是

）。那么这是否意味着当我使用C编程并使用标准的

库函数时，它类似于调用OS特定的API（相同的

类型的性能）？


看到在

内核/操作系统级别实现的所有这些标准库函数让我想要更多地使用C，因为它显然意味着

其他语言在更远的水平上实施。来自

系统（可能调用C库函数????）。


我的想法是正确还是我离开了？看到标准库函数在操作系统内核代码中实现，我是否感到非常兴奋？


澄清将会受到赞赏。

Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?

Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it''s similar to calling the OS specific APIs (same
type of performance)?

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?

Clarification will be appreciated.

推荐答案

" Romeo Colacitti" < WW ***** @ gmail.com>在消息中写道

news：11 ********************* @ g14g2000cwa.googlegro ups.com ...

"Romeo Colacitti" <ww*****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

大多数操作系统（即unix类型操作系统）的C库是在非常低的内核还是在内核级别之外实现的？

浏览Linux / BSD的源代码树看起来C / /库与OS交织在一起（string.h和其他标题都在那里）。那么这是否意味着当我使用C编程并使用标准的库函数时，它类似于调用OS特定的API（相同的性能类型）？

看到在内核/操作系统级别实现的所有这些标准库函数使我想要更多地使用C，因为它显然意味着其他语言在更远的级别上实现。来自
系统（可能调用C库函数????）。

我的想法是正确还是我离开了？我是否因为看到OS内核代码中实现的标准库函数而感到兴奋？

澄清将会受到赞赏。

Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?

Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it''s similar to calling the OS specific APIs (same
type of performance)?

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?

Clarification will be appreciated.

事情是，标准C库必须基于某些东西。这是一个操作系统内核（事实上，这不仅仅是C，它就像使用任何其他语言及其标准库一样的b / b
）。所以，两个人之间的关系是多么紧密和明确，而且根据定义，这就是

。

On另一方面，许多标准C函数都是通用且有用的，足以在OS内核中使用的
。是的，那些字符串函数，

转换函数，I / O函数，等等。因此，内核可以并且经常使用它们也可以使用它们。

关键的区别在于内核提供了一些基本功能，

通常非常低层次的。标准的C库和应用程序是建立在它们之上的b $ b，这些是更高级别的。但是（！）没有什么可以阻止你使用内核中的高级函数。我的意思是，内核确实使用了自己的低级功能，并且可以使用高级别的b $ b级功能，这是基于它的低级功能......你看，如果

你有sprintf（）并希望在内核中使用它，那么你可以这样做 - 你好b / b
不需要特殊版本的sprintf （）仅针对内核

本身。第二个会导致臃肿。你可以在内核中使用open（）/ fopen（）

，你应该可以因为内核（加上驱动程序）

无论如何都会为你提供文件访问权限，即使它处于低水平。如果

高级别更方便使用但不妥协内核，请执行

在内核中使用它。


Alex

The thing is, the standard C library MUST be based on something. This
something is the OS kernel (actually, this is true not only of C, it''s like
that with any other language and its standard library). So, it doesn''t
matter how tight and explicit the relationship between the two is, it is
there by definition.
On the other hand, lots of the standard C functions are generic and useful
enough to be used inside the OS kernel itself. Yes, those string functions,
conversion functions, I/O functions, whatever. So, the kernel MAY and often
DOES use them too.
The key difference is that the kernel provides some base functionality,
usually very low-level. The standard C library and the applications are
built on top of that, these are higher-level. BUT (!) there''s nothing that
prevents you from using the higher-level functions in the kernel. I mean,
the kernel does use its own low level functionality and may use the high
level functionality, which is based on its low level funcs... You see, if
you have sprintf() and want to use it in the kernel, you can do that -- you
don''t need to have a special version of sprintf() just for the kernel
itself. The 2nd would contribute to the bloat. You could use open()/fopen()
in the kernel, you should be able to because the kernel (plus the drivers)
will provide you with file access anyway, even though it''s on low level. If
high level is more convenient for use yet doesn''t compromise the kernel, do
use it in the kernel.

Alex

Romeo Colacitti写道：

Romeo Colacitti wrote:

大多数操作系统（即unix类型操作系统）的C库是否在
内核非常低或只是内核级别？


是的。


从C标准的角度来看（你已发布到

comp.lang.c），该库是实现的一部分

，实现的内部安排是

无论执行者选择什么。标准描述了

实现（包括库）必须做什么，

但不是必须如何完成。


在大多数实现中，库的某些部分完全是用户土地代码。但其他人需要O / S的一些帮助
帮助。用户土地上qsort（）可能完全运行
，但fopen（）很可能是用户和内核代码的混合物。


PJ Plauger的'标准C库'是典型的（C90）库实现的一个很好的

博览会。 （是的：

我最近似乎把这本书插了很多，但没有：

我没有收到佣金......）

查看Linux / BSD的源代码树，看起来C / /库与OS交织在一起（string.h和其他头文件都在那里）。那么这是否意味着当我使用C编程并使用标准的库函数时，它类似于调用OS特定的API（相同的性能类型）？


不同的系统会有不同的性能。关于我在这个非常复杂的主题上所做的所有打字，这是'b
;

其他人可能有更多的耐力。

看到所有这些标准库函数在内核/操作系统级别实现，这使我想要更多地使用C，因为它显然意味着其他语言在更远的水平上实现。来自
系统（可能调用C库函数????）。


非sequitur：事情是在内核中

并不能提供速度优势。在大多数

系统上，交叉和重新交叉用户/内核边界

确定了时间损失（< stdio.h>的部分工作是

减少过境次数）。即使内核代码

对于这个或那个函数比用户级版本更快，

a程序需要跳入和退出内核才能使用

更快的代码实际上可能运行得更慢。不要开车十几公里，以避免一个交通信号。


此外，如果个别微操作的表现是

对你来说非常重要，你不应该使用任何高级语言，

可以是C，Lisp，Java，Ada或COBOL。对于任何给定的编程

任务，O / S太笼统，因此太慢;丢弃它并且

实现您自己的专用版本。并且不要使用汇编

语言：使用手工制作的数字机器代码。你将获得最快的可实现的实现 - 对于一台将在你完成代码之前已经过时的机器将会过时...性能

远远不是最好的编程。

我的想法是正确的还是我离开了？我是否因为看到OS内核代码中实现标准库函数而感到兴奋？

Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?
"Yes."

From the C Standard''s point of view (you''ve posted to
comp.lang.c), the library is part of "the implementation"
and the internal arrangements of the implementation are
whatever the implementor chooses. The Standard describes
what the implementation (including the library) must do,
but not how it must be done.

In most implementations, some parts of the library are
entirely "user-land code" but others require some amount of
help from the O/S. It''s likely that qsort() runs entirely
in user land, but it''s likely that fopen() is a mixture of
user and kernel code.

P.J. Plauger''s "The Standard C Library" is a good
exposition of a typical (C90) library implementation. (Yes:
I seem to have plugged this book quite a lot recently, but no:
I don''t get a commission ...)
Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it''s similar to calling the OS specific APIs (same
type of performance)?
Different systems will have different performance. That''s
about all the typing I care to do on this very complex subject;
others may have more stamina.
Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).
Non sequitur: the fact that something is "in the kernel"
doesn''t in and of itself give a speed advantage. On most
systems, crossing and recrossing the user/kernel boundary
exacts a time penalty (part of the job of <stdio.h> is to
reduce the number of crossings). Even if the in-kernel code
for this or that function is faster than a user-land version,
a program that needs to hop in and out of the kernel to use
that faster code may actually run more slowly. Don''t drive
ten kilometers to avoid one traffic signal.

Also, if the performance of individual micro-operations is
all-important to you, you should not use ANY high-level language,
be it C, Lisp, Java, Ada, or COBOL. For any given programming
task, the O/S is too general and hence too slow; discard it and
implement your own specialized version. And don''t use assembly
language: use hand-crafted numeric machine code. You''ll have
the fastest imaginable implementation -- for a machine that will
have become obsolete before you finish your code ... Performance
is far from the be-all and end-all of good programming.
Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?

我想你是。 YMMV。


-

Eric Sosman
es ***** @ acm-dot-org.inva lid

I think you are. YMMV.

--
Eric Sosman
es*****@acm-dot-org.invalid

Eric Sosman< es ***** @ acm-点org.invalid>写道：

[...]

Eric Sosman <es*****@acm-dot-org.invalid> writes:
[...]

非sequitur：某事物是在内核中的事实
本身并不能给出速度优势。在大多数系统中，交叉和重新交叉用户/内核边界确定了时间损失（< stdio.h>的工作的一部分是减少交叉的数量）。即使内核代码对于这个或那个函数比用户级版本更快，
一个程序需要跳入和退出内核才能使用更快的代码可能实际上运行得更慢。不要行驶十公里以避免一个交通信号。

Non sequitur: the fact that something is "in the kernel"
doesn''t in and of itself give a speed advantage. On most
systems, crossing and recrossing the user/kernel boundary
exacts a time penalty (part of the job of <stdio.h> is to
reduce the number of crossings). Even if the in-kernel code
for this or that function is faster than a user-land version,
a program that needs to hop in and out of the kernel to use
that faster code may actually run more slowly. Don''t drive
ten kilometers to avoid one traffic signal.

一些C库函数可以在C中直接实现。

strlen（）就是一个很好的例子。如果操作系统内核是用C语言编写的，那么它需要某种类型的C库（尽管它可能不是一个完全符合要求的托管实现）。


我的猜测是strlen（）

函数只有一个实现，并且它可以从内核调用，也可以调用来自用户

代码，没有跨越用户/内核边界。这只是一个函数

来电。对于很多其他C库

函数也是如此。


-

Keith Thompson（The_Other_Keith ） ks***@mib.org < http://www.ghoti.net/~kst>

圣地亚哥超级计算机中心< *> < http://users.sdsc.edu/~kst>

我们必须做点什么。这是事情。因此，我们必须这样做。

Some C library functions can be implemented straightforwardly in C.
strlen() is a good example. If the OS kernel is written in C, it''s
going to need some sort of C library (though it may not be a fully
conforming hosted implementation).

My guess is that there''s only one implementation of the strlen()
function, and that it''s callable either from the kernel or from user
code without crossing the user/kernel boundary. It''s just a function
call. The same is going to be true for a lot of other C library
functions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

这篇关于[25％OT] C库OS /内核的组成部分???的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！