threads and kernel

DISCUSSION Shriramana Sharma 6 participants 20 messages Oct 21, 2007 – Oct 23, 2007

Share & tools

Shriramana Sharma

author

2007-10-21 13:21 UTC #0 lore raw

Hello, my knowledgeable friends! :)

As I understand it, the kernel is always running and whenever an app asks for a system resource the kernel does the needful. However, in my process tree I see no process named linux or kernel. I only see the init process at the root of the tree. Does the init process represent the kernel?

When an app does a system call, would some form of IPC between the process of that app and the kernel process (assuming there is one) be involved?

When an application uses a library, the app and the library are processed in DIFFERENT threads in which of the following cases:

1. the library is statically linked
2. the library is dynamically linked
3. the library is loaded using dlopen

My guess is "none of the above", am I right?

These are NOT homework questions! :)

Thanks, as always.

Shriramana Sharma.

Irfan Habib

2007-10-21 16:26 UTC #1 lore raw

unsubscribe linux-c-programming

Steve Graegert

2007-10-21 17:23 UTC #2 lore raw

In reply to Shriramana Sharma

Hello Shriramana,

your questions can be answered in very great detail and fill whole books (which has actually happened), so please forgive my brief answers.

(Comments inline)

Quoted 8 lines · Shriramana Sharma

Hello, my knowledgeable friends! :)
1.
As I understand it, the kernel is always running and whenever an app asks for a system resource the kernel does the needful. However, in my process tree I see no process named linux or kernel. I only see the init process at the root of the tree. Does the init process represent the kernel?

When the boot loader has finished loading the kernel image and invoked startup_32() on x86 systems the kernel spawns the scheduler (PID 0) and the init process (PID 1) separately. The scheduler then takes control over the system as soon as the kernel goes idle and init starts the /etc/rc.d/rc.sysinit script.

Yes, there is no kernel process, but there are a couple of other system processes: kflushd, kupdate, kpiod, kswapd, etc.

Quoted 5 lines

2.
When an app does a system call, would some form of IPC between the process of that app and the kernel process (assuming there is one) be involved?

Code typically runs in two or more privilege levels. Linux supports two levels known as user mode and kernel mode. Higher privileged code can perform operations which impact system performance and stability like accessing hardware devices, changing the processor state, enabling/disabling interrupts, etc.

System calls often make use of special CPU instructions that cause the processor to transfer control to a higher privilege level allowing the more privileged code to execute.

When a system call is invoked, the process which has invoked is being interrupted and all the information needed to continue this process is stored for later use. Now, the process executes higher privileged code that determines what to do next from examining the stack of the less privileged code. It contains information about the request to be served by the kernel. When it is finished, it control is returned to the program, restoring the saved state and continuing program execution.

The standard C library provides wrapper functions to make life easier for developers as the semantic of system calls is system dependent.

Quoted 10 lines

3.
When an application uses a library, the app and the library are processed in DIFFERENT threads in which of the following cases:
1. the library is statically linked
2. the library is dynamically linked
3. the library is loaded using dlopen
My guess is "none of the above", am I right?

Runtime linking of libraries is done at the process level.

Dynamic applications, for example, consist of a dynamic executable and one or more dynamic objects. As part of the initialization and execution of a dynamic application, runtime linker ld.so.1, performs the following functions:

1. analyze shared object dependencies,
2. locate and map in these dependencies,
3. calls initialization functions provided by the shared object,
4. transfer control to application's main() function.

From this moment on all threads created __within__ the process share its address space.

As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.

Quoted 1 line

These are NOT homework questions! :)

Yes, I know. You are a well known member of this list. No need to apologize.

\Steve

Steve Grägert
DigitalEther.de
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Benoit Fouet

2007-10-22 06:50 UTC #3 lore raw

Hi,

Quoted 6 lines · Steve Graegert

As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.

could you please elaborate a bit on that ? i cannot see why this is dangerous.

Thanks,

Ben

Steve Graegert

2007-10-22 13:01 UTC #4 lore raw

Hi Benoit,

Quoted 10 lines · Benoit Fouet

Hi,
Quoted 6 lines · Steve Graegert
As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.

Quoted 2 lines

could you please elaborate a bit on that ? i cannot see why this is dangerous.

I was referring to making an application multithreaded at runtime. Therefore you cannot use dlopen() to dynamically add libpthread.so to a process when the main program is not __initially threaded__. By "initially threaded" I mean that the libpthread.so library is initialized at program start, either because the main program links against libpthread.so directly, or because it links against some other shared library that links against libpthread.so.

Dynamically changing the process environment from "nonthreaded" to "threaded" is dangerous and rarely useful (I actually doubt that this "feature" is useful at all). Only a few systems implementing POSIX threads allow the possibility (for example, libc.so on many systems contains "stub" versions of the POSIX functions that are preempted by linking with libpthread.so but will not be preempted by later loading libpthread.so with dlopen()). In other words, calls to pthread_create() might fail with ENOSYS, and pthread_mutex_lock() might continue to succeed without any memory references to the lock.

\Steve

Benoit Fouet

2007-10-22 13:27 UTC #5 lore raw

Hi Steve,

Quoted 27 lines · Steve Graegert

Hi Benoit,
Quoted 11 lines · Benoit Fouet
Hi,
Quoted 7 lines · Steve Graegert
As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.
Quoted 3 lines
could you please elaborate a bit on that ? i cannot see why this is dangerous.
I was referring to making an application multithreaded at runtime. Therefore you cannot use dlopen() to dynamically add libpthread.so to a process when the main program is not __initially threaded__. By "initially threaded" I mean that the libpthread.so library is initialized at program start, either because the main program links against libpthread.so directly, or because it links against some other shared library that links against libpthread.so.

Quoted 3 lines

Dynamically changing the process environment from "nonthreaded" to "threaded" is dangerous and rarely useful (I actually doubt that this "feature" is useful at all).

If i understand correctly what you're saying, you cannot have something like:

int main(int argc, char *argv[]) {
/* ... */
foo = dlopen("bar.so");
/* use bar.so functions, clean, etc... */
}

if bar.so is multithreaded (and thus, linked to libpthread.so) and you don't compile your main program with -lpthread option.
did i understand you right ?

this would mean you may need to link against pthread library, just in case the library(ies) you dlopen might use it ?

Quoted 9 lines

Only a few systems implementing POSIX
threads allow the possibility (for example, libc.so on many systems contains "stub" versions of the POSIX functions that are preempted by linking with libpthread.so but will not be preempted by later loading libpthread.so with dlopen()). In other words, calls to pthread_create() might fail with ENOSYS, and pthread_mutex_lock() might continue to succeed without any memory references to the lock.

Ben

Steve Graegert

2007-10-22 13:31 UTC #6 lore raw

Benoit,

Quoted 43 lines · Benoit Fouet

Hi Steve,
Quoted 27 lines · Steve Graegert
Hi Benoit,
Quoted 11 lines · Benoit Fouet
Hi,
Quoted 7 lines · Steve Graegert
As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.
Quoted 3 lines
could you please elaborate a bit on that ? i cannot see why this is dangerous.
I was referring to making an application multithreaded at runtime. Therefore you cannot use dlopen() to dynamically add libpthread.so to a process when the main program is not __initially threaded__. By "initially threaded" I mean that the libpthread.so library is initialized at program start, either because the main program links against libpthread.so directly, or because it links against some other shared library that links against libpthread.so.
Quoted 3 lines
Dynamically changing the process environment from "nonthreaded" to "threaded" is dangerous and rarely useful (I actually doubt that this "feature" is useful at all).
If i understand correctly what you're saying, you cannot have something like:
int main(int argc, char *argv[]) {
/* ... */
foo = dlopen("bar.so");
/* use bar.so functions, clean, etc... */
}

Quoted 6 lines

if bar.so is multithreaded (and thus, linked to libpthread.so) and you don't compile your main program with -lpthread option.
did i understand you right ?
this would mean you may need to link against pthread library, just in case the library(ies) you dlopen might use it ?

Linking against a multi-threaded library at compile time, turns the main program into a multi-threaded program even though no use of threads is being made at all.

\Steve

Benoit Fouet

2007-10-22 13:38 UTC #7 lore raw

Hi,

Quoted 55 lines · Steve Graegert

Benoit,
Quoted 51 lines · Benoit Fouet
Hi Steve,
Quoted 30 lines · Steve Graegert
Hi Benoit,
Quoted 13 lines · Benoit Fouet
Hi,
Quoted 8 lines · Steve Graegert
As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.
Quoted 4 lines
could you please elaborate a bit on that ? i cannot see why this is dangerous.
I was referring to making an application multithreaded at runtime. Therefore you cannot use dlopen() to dynamically add libpthread.so to a process when the main program is not __initially threaded__. By "initially threaded" I mean that the libpthread.so library is initialized at program start, either because the main program links against libpthread.so directly, or because it links against some other shared library that links against libpthread.so.
Quoted 4 lines
Dynamically changing the process environment from "nonthreaded" to "threaded" is dangerous and rarely useful (I actually doubt that this "feature" is useful at all).
If i understand correctly what you're saying, you cannot have something like:
int main(int argc, char *argv[]) {
/* ... */
foo = dlopen("bar.so");
/* use bar.so functions, clean, etc... */
}
if bar.so is multithreaded (and thus, linked to libpthread.so) and you don't compile your main program with -lpthread option.
did i understand you right ?

Quoted 9 lines

Quoted 3 lines
this would mean you may need to link against pthread library, just in case the library(ies) you dlopen might use it ?
Linking against a multi-threaded library at compile time, turns the main program into a multi-threaded program even though no use of threads is being made at all.

i agree, but this was not what i asked.
consider a library foo using threads.
consider a main program bar only linked to dl.
chat you said is that bar cannot use sanely foo functions, because it is not multithreaded itself, right ?

Ben

Steve Graegert

2007-10-22 14:20 UTC #8 lore raw

Quoted 68 lines · Benoit Fouet

Hi,
Quoted 55 lines · Steve Graegert
Benoit,
Quoted 51 lines · Benoit Fouet
Hi Steve,
Quoted 30 lines · Steve Graegert
Hi Benoit,
Quoted 13 lines · Benoit Fouet
Hi,
Quoted 8 lines · Steve Graegert
As a side note: you can safely use dlopen() to load shared libraries, whether or not they depend on libpthread.so, as long as the main program was initially threaded. The other way round is dangerous and mostly not allowed.
Quoted 4 lines
could you please elaborate a bit on that ? i cannot see why this is dangerous.
I was referring to making an application multithreaded at runtime. Therefore you cannot use dlopen() to dynamically add libpthread.so to a process when the main program is not __initially threaded__. By "initially threaded" I mean that the libpthread.so library is initialized at program start, either because the main program links against libpthread.so directly, or because it links against some other shared library that links against libpthread.so.
Quoted 4 lines
Dynamically changing the process environment from "nonthreaded" to "threaded" is dangerous and rarely useful (I actually doubt that this "feature" is useful at all).
If i understand correctly what you're saying, you cannot have something like:
int main(int argc, char *argv[]) {
/* ... */
foo = dlopen("bar.so");
/* use bar.so functions, clean, etc... */
}
if bar.so is multithreaded (and thus, linked to libpthread.so) and you don't compile your main program with -lpthread option.
did i understand you right ?
Quoted 9 lines
Quoted 3 lines
this would mean you may need to link against pthread library, just in case the library(ies) you dlopen might use it ?
Linking against a multi-threaded library at compile time, turns the main program into a multi-threaded program even though no use of threads is being made at all.

Quoted 5 lines

i agree, but this was not what i asked.
consider a library foo using threads.
consider a main program bar only linked to dl.
chat you said is that bar cannot use sanely foo functions, because it is not multithreaded itself, right ?

Basilcally yes, but let me summarize some important points:

Suppose you have an application that is not linked against libpthread, neither directly nor indirectly (just as you stated earlier). The init code used to set up the main program doesn't care about threads, because it assumes that they won't be used anyway. Hence you have a non-threaded program. The important thing is the init code, not whether the main program makes call to pthread_* and its siblings or not.

Now, this non-thread program loads a shared object using dlopen() which is linked against libpthread, thus resulting in an "abort trap".

I remember Apache to crash with an abort trap when loading mod_perl although it has been build without errors. Recompiling apache with CFLAGS+=-pthread fixed the problem.

Example:

#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
	void *h;  // the handle

	printf("Trying to load libpthread.so\n");
	h = dlopen("libpthread.so", RTLD_LAZY);
	printf("libpthread.so loaded successfully\n");
	dlclose(h);

	return EXIT_SUCCESS;
}

This can be worked around by linking against libpthread, because this causes the initialization code used to set up the program to be overridden.

Considering the previous example, doing:

cc test.c
./a.out

results in a crash. But

cc -lpthread test.c
./a.out

won't. Even

cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out

will work. It's the initialization code that matters, not if threads are used or not.

\Steve

Benoit Fouet

2007-10-22 14:34 UTC #9 lore raw

Quoted 6 lines · Steve Graegert

[...]
It's the initialization code that matters, not if threads are used or not.

ok, thanks for explaining

Ben

vibi

2007-10-23 04:32 UTC #10 lore raw

In reply to Steve Graegert

Quoted 1 line

"The init code used to set up the main program doesn't care about threads,

because it assumes that they won't be used anyway."

when is init code linked to the program ,during the compile time or during the run time?

thanks in advance
regards
vibi sreenivasan

Steve Graegert

2007-10-23 05:14 UTC #11 lore raw

Quoted 6 lines · vibi

Quoted 1 line
"The init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway."
when is init code linked to the program ,during the compile time or during the run time?

It's being added by the linker at compile time.

\Steve

vibi

2007-10-23 05:53 UTC #12 lore raw

Quoted 11 lines · Steve Graegert

Quoted 6 lines · vibi
Quoted 1 line
"The init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway."
when is init code linked to the program ,during the compile time or during the run time?
It's being added by the linker at compile time.
\Steve

the application you gave earlier is linked without any knowledge of multi-threading
so

Quoted 2 lines

cc test.c
./a.out

would fail

but you also said

Quoted 2 lines

cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out

will not fail

in both the cases same init code is added at compile time and you also said that init code determines whether a program is multi-threaded.

So i am a little bit confused because how at run time the init code is changed.

regards
vibi sreenivasan

Quoted 4 lines

Steve GrÃ¤gert
DigitalEther.de

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Steve Graegert

2007-10-23 06:58 UTC #13 lore raw

Quoted 27 lines · vibi

Quoted 11 lines · Steve Graegert
Quoted 6 lines · vibi
Quoted 1 line
"The init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway."
when is init code linked to the program ,during the compile time or during the run time?
It's being added by the linker at compile time.
\Steve
the application you gave earlier is linked without any knowledge of multi-threading
so
Quoted 2 lines
cc test.c
./a.out
would fail
but you also said
Quoted 2 lines
cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out

Quoted 7 lines

will not fail
in both the cases same init code is added at compile time and you also said that init code determines whether a program is multi-threaded.
So i am a little bit confused because how at run time the init code is changed.

Linkage takes place at compile time and run time. When starting a program its execution environment is setup properly including loading and linking in all libraries (including those specified on the command line with LD_PRELOAD and at compile time).

The LD_PRELOAD environment variable allows you to load additional shared libraries at program startup. The loader ld.so.1, loads the specified shared libraries as if the program had been linked explicitly with the shared libraries in LD_PRELOAD before any other dependents of the program. At startup time, the loader implicitly loads one or more libraries, if found, specified in the LD_PRELOAD environment. It uses the same load order and symbol resolution order as if the library had been explicitly linked as the first library in the link line when building the executable.

As a result, at startup the program is multi-threaded when LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is neither specified at compile time nor __before__ startup of the main program (i.e. LD_PRELOAD) the execution environment is unchanged (not threaded at all).

This is possible because the init code of the libraries is executed at before control is transfered to the main program, thus the program is multi-threaded although libpthread has no been specified at compile time and no thread-related function calls are made during runtime.

\Steve

vibi

2007-10-23 07:10 UTC #14 lore raw

Quoted 57 lines · Steve Graegert

Quoted 27 lines · vibi
Quoted 11 lines · Steve Graegert
Quoted 6 lines · vibi
Quoted 1 line
"The init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway."
when is init code linked to the program ,during the compile time or during the run time?
It's being added by the linker at compile time.
\Steve
the application you gave earlier is linked without any knowledge of multi-threading
so
Quoted 2 lines
cc test.c
./a.out
would fail
but you also said
Quoted 2 lines
cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out
Quoted 7 lines
will not fail
in both the cases same init code is added at compile time and you also said that init code determines whether a program is multi-threaded.
So i am a little bit confused because how at run time the init code is changed.
Linkage takes place at compile time and run time. When starting a program its execution environment is setup properly including loading and linking in all libraries (including those specified on the command line with LD_PRELOAD and at compile time).
The LD_PRELOAD environment variable allows you to load additional shared libraries at program startup. The loader ld.so.1, loads the specified shared libraries as if the program had been linked explicitly with the shared libraries in LD_PRELOAD before any other dependents of the program. At startup time, the loader implicitly loads one or more libraries, if found, specified in the LD_PRELOAD environment. It uses the same load order and symbol resolution order as if the library had been explicitly linked as the first library in the link line when building the executable.
As a result, at startup the program is multi-threaded when LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is neither specified at compile time nor __before__ startup of the main program (i.e. LD_PRELOAD) the execution environment is unchanged (not threaded at all).

Quoted 6 lines

This is possible because the init code of the libraries is executed at before control is transfered to the main program, thus the program is multi-threaded although libpthread has no been specified at compile time and no thread-related function calls are made during runtime.
\Steve

so init code is just like a stub which is resolved while setting up the execution environment of the program,ie linkage resolution at load time.

am i understanding correctly.

thanks very much for your help
regards
vibi sreenivasan

Quoted 6 lines

--
Steve GrÃ¤gert
DigitalEther.de

-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Steve Graegert

2007-10-23 07:30 UTC #15 lore raw

Quoted 63 lines · vibi

Quoted 62 lines · Steve Graegert
Quoted 27 lines · vibi
Quoted 11 lines · Steve Graegert
Quoted 6 lines · vibi
Quoted 1 line
"The init code used to set up the main program doesn't care about threads,
because it assumes that they won't be used anyway."
when is init code linked to the program ,during the compile time or during the run time?
It's being added by the linker at compile time.
\Steve
the application you gave earlier is linked without any knowledge of multi-threading
so
Quoted 2 lines
cc test.c
./a.out
would fail
but you also said
Quoted 2 lines
cc test.c
LD_PRELOAD=/usr/lib/libpthread.so ./a.out
Quoted 7 lines
will not fail
in both the cases same init code is added at compile time and you also said that init code determines whether a program is multi-threaded.
So i am a little bit confused because how at run time the init code is changed.
Linkage takes place at compile time and run time. When starting a program its execution environment is setup properly including loading and linking in all libraries (including those specified on the command line with LD_PRELOAD and at compile time).
The LD_PRELOAD environment variable allows you to load additional shared libraries at program startup. The loader ld.so.1, loads the specified shared libraries as if the program had been linked explicitly with the shared libraries in LD_PRELOAD before any other dependents of the program. At startup time, the loader implicitly loads one or more libraries, if found, specified in the LD_PRELOAD environment. It uses the same load order and symbol resolution order as if the library had been explicitly linked as the first library in the link line when building the executable.
As a result, at startup the program is multi-threaded when LD_PRELOAD=/usr/lib/libpthread.so is specified, but if libpthread is neither specified at compile time nor __before__ startup of the main program (i.e. LD_PRELOAD) the execution environment is unchanged (not threaded at all).
This is possible because the init code of the libraries is executed at before control is transfered to the main program, thus the program is multi-threaded although libpthread has no been specified at compile time and no thread-related function calls are made during runtime.

Quoted 6 lines

Quoted 1 line
\Steve
so init code is just like a stub which is resolved while setting up the execution environment of the program,ie linkage resolution at load time.
am i understanding correctly.

Well, it's not a stub, since it's a very important section of the executable.

The .init section holds executable instructions that contribute to the process initialization code. That is, when a program starts to run the system arranges to execute the code in this section before the main program entry point (main() in C programs).

The .init and .fini sections have a special purpose. If a function is placed in the .init section, the system will execute it before the main function. Also the functions placed in the .fini section will be executed by the system after the main function returns. This feature is utilized by compilers to implement global constructors and destructors in C++.

Also, any shared object file included in the program also has an opportunity to run its initialization code before the call to the main program.

\Steve

Shriramana Sharma

author

2007-10-22 07:55 UTC #16 lore raw

In reply to Steve Graegert

Quoted 3 lines · Steve Graegert

your questions can be answered in very great detail and fill whole books (which has actually happened), so please forgive my brief answers.

Brief answers are sufficient. Thank you. :)

Quoted 3 lines

and the init process (PID 1) separately. The scheduler then takes control over the system as soon as the kernel goes idle and init starts the /etc/rc.d/rc.sysinit script.

So would the kernel be "reawakened" by some external event occurring, as Glynn wrote? I am thinking like -- the kernel is a body of instructions, just like any other program. So like I do something (type "cp" at a terminal, for ex) to have the program called "cp" to be processed -- that is, the instructions in it are executed. Similarly when a system call is made by any program, the instructions contained in the kernel would be executed. Is this understanding right?

Quoted 8 lines

When a system call is invoked, the process which has invoked is being interrupted and all the information needed to continue this process is stored for later use. Now, the process executes higher privileged code that determines what to do next from examining the stack of the less privileged code. It contains information about the request to be served by the kernel. When it is finished, it control is returned to the program, restoring the saved state and continuing program execution.

So technically the kernel instructions would be processed "in" the same process and thread that makes the system call, albeit with different privelege, right? Or is the process *making the system call* totally "paused", as in a "wait" situation when one process waits for another to finish?

Do I also understand right that the kernel resides in a special section of memory the boot loader puts it in? The core of the kernel (apart from dynamically loadable kernel modules) is the vmlinuz file sitting in my /boot dir, right?

Quoted 1 line

Yes, I know. You are a well known member of this list. No need to apologize.

Oh thanks -- that was very nice of you to say. I only thought -- these are probably very basic questions for my friends here, and so may seem like homework questions. :)

Have a nice day, all! :)

Shriramana Sharma.

Steve Graegert

2007-10-22 13:41 UTC #17 lore raw

Quoted 5 lines · Shriramana Sharma

Quoted 3 lines · Steve Graegert
your questions can be answered in very great detail and fill whole books (which has actually happened), so please forgive my brief answers.

Quoted 8 lines

Brief answers are sufficient. Thank you. :)
Quoted 3 lines
and the init process (PID 1) separately. The scheduler then takes control over the system as soon as the kernel goes idle and init starts the /etc/rc.d/rc.sysinit script.
So would the kernel be "reawakened" by some external event occurring, as Glynn wrote?

Yes, exactly.

Quoted 6 lines

I am thinking like -- the kernel is a body of instructions, just like any other program. So like I do something (type "cp" at a terminal, for ex) to have the program called "cp" to be processed -- that is, the instructions in it are executed. Similarly when a system call is made by any program, the instructions contained in the kernel would be executed. Is this understanding right?

That is basically correct.

Quoted 9 lines

Quoted 8 lines
When a system call is invoked, the process which has invoked is being interrupted and all the information needed to continue this process is stored for later use. Now, the process executes higher privileged code that determines what to do next from examining the stack of the less privileged code. It contains information about the request to be served by the kernel. When it is finished, it control is returned to the program, restoring the saved state and continuing program execution.

Quoted 5 lines

So technically the kernel instructions would be processed "in" the same process and thread that makes the system call, albeit with different privelege, right? Or is the process *making the system call* totally "paused", as in a "wait" situation when one process waits for another to finish?

Well, no.

Whenever a user program is invoked a new process is created. Nevertheless, the system call is handled in the kernel's address space which is made available by a "context switch" (int 0x80) from user mode to kernel mode.

When a process requests the kernel to do something which is currently impossible but that may become possible later, the process is put to sleep and is woken up when the request is more likely to be satisfied. One of the kernel mechanisms used for this is called a "wait queue".

When a userspace application makes a system call, the arguments are passed via registers and the application executes "int 0x80" (x86) instruction. This causes a trap into kernel mode and processor jumps to system_call entry point in entry.S. What this does is:

1. Save registers.
2. Set %ds (data segment) and %es (extra segment) to KERNEL_DS,
allowing the references to be made in the kernel address space.
3. If the value of %eax (the system call number supposed to serve
the request is stored here) is greater than NR_syscalls (max no. of system calls, currently 256), fail with ENOSYS error.
4. Call sys_call_table (initialized at boot up) with syscall_number
argument from %eax. This table (arch/i386/kernel/entry.S) points to individual system call handlers which will find their arguments on the stack.
5. Enter the so called "system call return path" checking if a call
to schedule() is needed, checking for pending signals and if so handling them.
6. Check for errors

Quoted 4 lines

Do I also understand right that the kernel resides in a special section of memory the boot loader puts it in? The core of the kernel (apart from dynamically loadable kernel modules) is the vmlinuz file sitting in my /boot dir, right?

Short answer: yes.

Long answer: Linux actually implements a two stage boot process. In the first stage, the BIOS loads the boot program (Initial Program Loader) from the hard disk to the memory. In the second stage, the boot program loads the operating system kernel vmlinuz into memory and uncompresses it, since vmlinuz is a compressed kernel image (protected mode).

When the kernel loads into memory, it performs a memory test. Most of the kernel data structures are initialized statically. So it sets aside a part of memory for kernel use. This part of the memory cannot be used by any other processes. It also reports the total amount of physical memory available and sets aside those for the user processes.

Hope that was helpful.

\Steve

Glynn Clements

2007-10-22 17:18 UTC #18 lore raw

In reply to Shriramana Sharma

Quoted 9 lines · Shriramana Sharma

Quoted 8 lines
When a system call is invoked, the process which has invoked is being interrupted and all the information needed to continue this process is stored for later use. Now, the process executes higher privileged code that determines what to do next from examining the stack of the less privileged code. It contains information about the request to be served by the kernel. When it is finished, it control is returned to the program, restoring the saved state and continuing program execution.

Quoted 5 lines

So technically the kernel instructions would be processed "in" the same process and thread that makes the system call, albeit with different privelege, right? Or is the process *making the system call* totally "paused", as in a "wait" situation when one process waits for another to finish?

The kernel is a completely different "process" in so far as it has a separate task descriptor, and thus a different memory layout etc.

The system call is executed in the same "flow" in that the INT-80 instruction causes the CPU to start executing kernel code; after the system call has completed, control will eventually return to the calling process at the instruction after the INT-80.

In that sense, it's similar to a function call, but the similarity largely stops there.

Signature · 1 line

Glynn Clements <[email protected]>

Glynn Clements

2007-10-21 17:36 UTC #19 lore raw

In reply to Shriramana Sharma

Quoted 1 line · Shriramana Sharma

As I understand it, the kernel is always running

Not in the same sense that a process is "running". Most of the time, it's "blocked" waiting for some external event to occur and give it something to do.

Quoted 4 lines

and whenever an app
asks for a system resource the kernel does the needful. However, in my process tree I see no process named linux or kernel. I only see the init process at the root of the tree. Does the init process represent the kernel?

No. "init" is /sbin/init. It's a normal process, albeit a fairly important one.

Quoted 3 lines

When an app does a system call, would some form of IPC between the process of that app and the kernel process (assuming there is one) be involved?

In some ways, a system call is just like a function call. The main difference is that the kernel code is invoked through a software interrupt or trap, which causes the code to execute in the kernel's context rather than the application's context. Apart from having a completely different memory layout, the kernel code runs with increased privileges (ring 0 on i386, supervisor mode on 680x0, etc).

If you want to know the details, you'll need to read a reference book for the particular type of CPU.

Quoted 8 lines

When an application uses a library, the app and the library are processed in DIFFERENT threads in which of the following cases:
1. the library is statically linked
2. the library is dynamically linked
3. the library is loaded using dlopen
My guess is "none of the above", am I right?

Correct. Many applications don't use threads at all. Even for those which do, any calls to a library function are executed in the same thread as the code which call it.

Signature · 1 line

Glynn Clements <[email protected]>