Two levels of execution are provided by hardware: kernel mode execution and user mode execution. When in kernel mode, the software program can access all the instructions and every accessible piece of hardware. A program is in kernel space if running in kernel mode and in user space if running in user mode.
The Solaris kernel is a monolithic kernel, much like most Unix systems, as compared to a microkernel.
The software said to be running in kernel mode is. On the other hand, in user mode, the software cannot access certain some areas of functionality of the hardware. This prevents malicious programs from doing any damage to hardware.
In Monolithic kernels, the parts of the kernel that need to be accessible by most programs are placed in the kernel space. In other words, "the entire kernel is run in kernel space in supervisor mode" [3]. The examples of programs that are in the kernel space include device drivers, memory managers, scheduler, file systems etc.
For a program to be in kernel space, does not necessarily means that a program in user space cannot access its services. A number of system calls are made available to applications so they can access the services of programs that are running in kernel space.
Certain common libraries are not available to programmers programming in kernel space, which makes coding in that environment a bit harder. The problems and limitations associated with monolithic kernels does not end here. Debugging in kernel space is also hard due to the lack of quality debugging tools. For many changes to take effect, rebooting the system is required. Uncatched bugs in one kernel module can bring down the system.
Microkernel systems, on the other hand, place only those parts in kernel space for which being privileged is a requirement. These programs include IPC, basic schedulers, memory handling (basic) and I/O (basic). Other parts, such as memory handling and file systems, that could operate without being in privilege mode were moved to user space.
Solaris kernel, just like the Linux and FreeBSD kernels, are modular in the sense that they can dynamically (at runtime) load and unload modules. Using this dynamic nature of loading modules, the functionality and capability of kernels can be extended.
The Solaris kernel threads model is based on kernel threads, user threads, process and lightweight process objects.
Out of the four objects, it is the kernel threads object that is scheduled for execution, and then executed, on a processor.
Each user process also maintains a non-kernel thread state in the form of user threads.
Each user program has an execution environment known as process. The term process is also used to refer to the executable form of a program. Each process has, at the minimum, one thread of execution.User threads created inside the process are visible to the kernel. The execution context of a user thread is known as lightweight process, commonly abbreviated as LWP.
The kernel threads are executed by the kernel for tasks related to and needed by the kernel.
The execution state of a kernel thread is saved for later restoration when it is moved off the process for later scheduling.
Thanks to the virtual file system implementation in Solaris OS, we can configure multiple types of file systems at the same time.
As you can expect, complete support for IPv4 and IPv6 is implemented in the networking subsystem of the Solaris kernel.
The following types of loadable kernel modules are supported by the Solaris module framework:
- file systems (UFS, NFS)
- scheduler classes (Fixed Priority (FX), Real Time (RT) etc)
- execute file format loaders
- loadable system calls (semsys Semaphores)
- streams modules
- bus/device drivers (PCI)
- other/miscellaneous modules (IPC)
Solaris 8 introduced a single-level model for threads model. With the new single-level model, an LWP and kernel thread are created for each new user thread. The benefit of that is that the user thread always has a LWP and a kernel thread.
Thread applications link to libthread.so, typically placed in /usr/lib directory. On my Sun V210 with Solaris 10, the /usr/lib/libthread.so links to /lib/libthread.so.1
-bash-3.00$ ls -ltr /usr/lib/libthread.so
lrwxrwxrwx 1 root root 24 Mar 30 2005 /usr/lib/libthread.so -> ../../lib/libthread.so.1
If you are still using Solaris 8, the new binary based on single-level model is fully compatible with older model. Applications do not need to be recompiled to use the single-level model binary. On Solaris 8, all we need to do is point the runtime linker's path environmental variable to the new binary. On Solaris 10, the default library is the single-model one. The benefits of the new threads model include improved performance, scalability, and reliability, reliable signal behavior, improved adaptive mutex lock implementation and user-level sleep queues for synchronization objects4.
The scheduling classes in Solaris are TS (Timeshare), IA (interactive [enchanced TS]), FSS (fair-share scheduling), FX (fixed-priority), SYS (system), RT (real-time) and interrupts. The interrupts have the highest priority (160-169).
When you are using Windows, the IA schedule class is being used as it increases the thread priority for the window that has the focus.
Resources:
1. Linux Kernel Archives Provides the Linux kernel source and more
2. Monolithic kernels and micro-kernels
3. Monolithic kernel
4. Solaris Internals
No comments:
Post a Comment