Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [25% OT] C library integral part of OS/kernel???

Reply
Thread Tools

[25% OT] C library integral part of OS/kernel???

 
 
Romeo Colacitti
Guest
Posts: n/a
 
      03-06-2005
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.

 
Reply With Quote
 
 
 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      03-06-2005
"Romeo Colacitti" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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.



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


 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-06-2005
Romeo Colacitti wrote:
> 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?


I think you are. YMMV.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-06-2005
Eric Sosman <(E-Mail Removed)> writes:
[...]
> 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.


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) (E-Mail Removed) <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.
 
Reply With Quote
 
Romeo Colacitti
Guest
Posts: n/a
 
      03-07-2005
Keith Thompson wrote:
> Eric Sosman <(E-Mail Removed)> writes:
> [...]
> > 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.

>


snip

>
> 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.
>


I've even seen some "redefinitions" of library functions in kernel code
for unix-type operating systems. Something like:

#include <stdio.h>
int getchar()
{
return getchar();
}

So this suggests that these kernel writers are trying to get these C
functions to "propogate" in future versions of the kernel - I think.
So I guess compiling the code for the kernel, creates the standard
library in the kernel itself. It seems like the standard library is as
much important to these OSes as POSIX functions, etc. I guess this is
another reason why C is considered efficient - it's library is closer
to kernel (or part of it).

 
Reply With Quote
 
Maxim S. Shatskih
Guest
Posts: n/a
 
      03-07-2005
> 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????).


Yes. Usually, it is so.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(E-Mail Removed)
http://www.storagecraft.com


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      03-07-2005
Romeo Colacitti wrote:
>
> I've even seen some "redefinitions" of library functions in kernel code
> for unix-type operating systems. Something like:
>
> #include <stdio.h>
> int getchar()
> {
> return getchar();
> }


I hope "something like" means "rather different."
There are two invocations of undefined behavior in the
above, and if they don't bite you the remaining problem
surely will ...

Recursion (n): see "recursion."

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      03-07-2005
In <(E-Mail Removed)> Keith Thompson <(E-Mail Removed)> writes:

>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.


Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.

The source code of the kernel's strlen() may be the same as the
source code of the C library's strlen(), but they're still completely
separate entities, that can be maintained independently (kernel people
and library people are not necessarily the same). Nontrivial
functions, like malloc and friends may have completely different
implementations.

Dan
--
Dan Pop <(E-Mail Removed)>
 
Reply With Quote
 
Luke Wu
Guest
Posts: n/a
 
      03-08-2005
Romeo Colacitti wrote:
> 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)?
>


The C library is usally integrated into the OS, but not the kernel part
of it. The code you saw in the kernel code is for use by the kernel
developers. But part of what you're saying is right (see below).

>
> 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.


The library is implemented as part of the userland of the OS (which is
GNU not linux) - libc. That's why all the standard C library functions
are in the man pages, where as the C++, python, perl are not. The
standard C library is considered part of the "OS's SYSTEM CALLS." So
it is in the 'OS' , but not the kernel (the userland part of the OS).
This can only be said for the C library, no the C++, perl, python etc
(which incidentally could be calling/using the C library system calls)
- outside the userland.

 
Reply With Quote
 
Luke Wu
Guest
Posts: n/a
 
      03-08-2005
Luke Wu wrote:
> Romeo Colacitti wrote:
>
> The library is implemented as part of the userland of the OS (which

is
> GNU not linux) - libc. That's why all the standard C library

functions
> are in the man pages, where as the C++, python, perl are not. The
> standard C library is considered part of the "OS's SYSTEM CALLS." So
> it is in the 'OS' , but not the kernel (the userland part of the OS).
> This can only be said for the C library, no the C++, perl, python etc
> (which incidentally could be calling/using the C library system

calls)
> - outside the userland.


This diagram better compares the API provided by other languages, with
the API provided by C (for unix/linux). As you can see, LIBC is
"closer" to the kernel, but not "in" the kernel.

JAVA API
|
\/
JVM
/ \
POSIX LIBC(c api)
| |
\/ \/
SYSTEM CALLS
|
_____ \/_____
| KERNEL |
|___________|

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C++ 42 11-04-2008 12:39 PM
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C Programming 45 11-04-2008 12:39 PM
Largest value of an unsigned integral type Dave C++ 3 11-07-2003 06:51 AM
overload resolution / integral promotion / standard Alexander Stippler C++ 6 10-30-2003 10:47 AM
Integral smart card reader? Ged Computer Support 1 10-22-2003 08:54 AM



Advertisments