Re: [aclug-L] Kernel transportability
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Nate Bargmann wrote:
>
> John Goerzen wrote:
>
> > libc is a higher level than the kernel. The kernel doesn't care which libc
> > you're using, as long as it's 5 or greater (4 was for a different executable
> > format).
>
> hmmmm...
>
> Apparently I have much to learn regarding the relationship between the
> kernel and the C library. My assumption (mistake?) is that since the
> kernel is written mostly in C that it must use the services of whatever
> library /lib/libc.so points to. Does it not, or does it simply
> statically link all the relavant libc code? Logically, I can see where
> the kernel cannot rely on a dynamically linked library as it does many
> things before the file systems are mounted. Also, I can see that if the
> kernel uses statically linked code in its C routines, that would allow
> it to run on a glibc based system even if compiled on a libc5 based
> system. Have I guessed right?
Well... Sorta and sorta not...
The kernel does not use any libc calls persay, as there is not much of
interast there to the Kernel. Any calls it did make, would HAVE to be
staticly linked. But consider what is actually IN libc...
Most of the stuff in libc is "front ends" to actual kernel calls, and
you are not likely going to get away with putting a "printf" in a driver
and expect it to work (because it calls the kernel I/O routines). Most
of what the kernel needs, is hand coded into the kernel or macroed in,
so you are not going to need libc at all, or even want to use libc...
If you did use a libc call, you would have to be *very* careful not to
call anything that used kernel calls, or you could end up crashing the
system with endless recursive calls that would quickly use up any
available memory. Not a pretty sight.
I would guess, then, that external lib calls are not allowed with
writing kernel code... Kernel code cannot use all the nice things
available in user programs... Buffered File I/O, file opens, file
closing and the like. All these things are actualy done *by* the kernel
for everybody else and I'd bet you would just have to use the Kernel
calls directly to accomplish these things, instead of leaning on libc to
isolate you from such details.
But hey.. I'm not a kernel programmer... I've dabbled in device drivers,
but never actually got one to work yet...
-= bob =-
---
This is the Air Capitol Linux Users Group discussion list. If you
want to unsubscribe, send the word "unsubscribe" to
aclug-L-request@xxxxxxxxxxxx. If you want to post to the list, send your
message to aclug-L@xxxxxxxxxxxx.
- [aclug-L] Kernel transportability, Greg House, 1998/11/15
- Re: [aclug-L] Kernel transportability, Cheez-Czar, 1998/11/15
- Re: [aclug-L] Kernel transportability, Nate Bargmann, 1998/11/16
- Re: [aclug-L] Kernel transportability, Nate Bargmann, 1998/11/16
- Re: [aclug-L] Kernel transportability, John Goerzen, 1998/11/17
- Re: [aclug-L] Kernel transportability, Nate Bargmann, 1998/11/17
- Re: [aclug-L] Kernel transportability, John Goerzen, 1998/11/17
- Re: [aclug-L] Kernel transportability, Nate Bargmann, 1998/11/17
- Re: [aclug-L] Kernel transportability,
Bob Deep <=
Re: [aclug-L] Kernel transportability, Bob Deep, 1998/11/16
Re: [aclug-L] Kernel transportability, John Goerzen, 1998/11/17
|
|