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) On 10/21/07, Shriramana Sharma <samjnaa@xxxxxxxxx> wrote: > 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. > 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. > 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. > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
