0
when a process or anything makes a system call ,it goes in kernel(operating system).
Wiki User
∙ 11y ago
Add your answer:
Earn +20 pts
What characteristics make up an operating system?
The four major parts are: the kernel, process manager, file manager and scheduler
When a user-level thread executes a system call not only is that thread blocked but also all the threads within the process are blocked Why is that so?
A system call is actually a transition from user mode to kernel space to carry out a required operation.. For exp: Write() function resides in kernel space and can be accessed by a only corresponding wrapper function which was implemented in user space.. In case of Windows OS, Win32 API is the implementation to such as wrapper functions that make the actual system calls from user mode.. A kernel thread is created, scheduled and destroyed by the kernel.. Whereas a library thread (user thread) is created, scheduled and destroyed by a user level library like special threading libraries.. The kernel does know of nothing about library threads since they live in a process's boundaries and bound to its life cycle tightly.. Actually, a process is not the primary execution unit in all operating systems.. When a process is made by kernel, a new kernel thread is created and attached to that process in question.. So the library threads created in user mode by a user mode library must share the time slices given to the kernel thread by the scheduler arbitrarily during the lifetime of a process.. So a process actually has one kernel thread and all other library threads have to share the kernel thread's cycles.. Hence when a library thread makes a blocking call, all the threads within the process are blocked because as I said, actually process has only one kernel thread assigned to it and others try to make use of it.. So to prevent other threads from blocking, either you should use library threads that make use of kernel threads or you could just use the CreateThread() Win32 API system function for kernel threads but the synchronization mechanism must be provided by the programmer using events, signals, mutex, semaphore etc.. Sun, BSD Unix flavours, Windows etc follow the same threading architecture in their systems as POSIX standard.. However, a thread is a process in Linux.. That's why Linux is so powerful in server systems.. So the control is left to programmers to create a POSIX way of treading model by Clone(2) system call(s).. So address space and data etc can be shared by lightweight processes easily.. When a Linux kernel thread (child process) is crashed, it won't affect the rest of the threads belong to parent process.. This is just the opposite in other operating systems that a crashing thread will destroy all of the threads in the process.. NPTL is a great threading library that was implemented by using Linux clone(2) system call.. Linux also has another type of kernel thread only lives in kernel space that can be utilized by kernel code like modules.. User threads can't be run in parallel on the different CPUs because of this. However, they are portable.. Kernel threads can be scheduled by kernel to be run on a SMP system.. Hope this helps.. hsaq19@ TH Algan
What is the Linux kernel?
The Linux kernel is the central component of the GNU/Linux operating system. The kernel is the lowest level of interaction between the hardware and the operating system. Individual applications are at a higher level. The kernel along with supporting applications make up the operating system.
Give One difference between operating system software and applications software?
The OS makes calls to the system kernel (although sometimes the kernel is bundled with the OS). Applications make their calls to the OS, which then makes calls to the kernel.
How system call execute?
For a user most system calls are simply wrapped in simple command utilities such as chroot and mkdir and the like. But system calls proper are made by software, plain and simple. Usually how it works on the low level is dependent on the architecture being used. For "simplicity" I'll refer to x86(_64). When a system call is made, it's done by putting the parameters of the call in a series of general purpose registers in the CPU, then either signaling an interrupt or, in the case of 64-bit x86, actually using the syscall instruction. What happens then is a context switch occurs, and the CPU is switched over to kernel mode and the kernel itself is actually running now and has your system call. Meanwhile, the process that made the system call is put in the "blocked" list until the needs of the system call are met. Remember that a system call is a simple request for a service from the operating system by something in user space. Things in user space can't do a whole lot themselves in reality, and have to ask the operating system for a lot of support. While an application can do a lot with the CPU, as soon as it needs any sort of hardware support, or more memory, or less memory, it has to ask the operating system for it. For example: I wrote a text document in vi. To save, vi has to make a system call (Actually, a LOT of system calls.) to the kernel to actually write the buffer to disk. Think of system calls as being among the building blocks of the actual execution of software on *nix systems. The process will happily use CPU instructions without operating system help, but applications make constant use of hardware in some way, and to do that, they have to use instructions for the kernel, who may or may not actually GRANT the requests based on permissions or sanity of the system call, as opposed to a CPU which will MOSTLY do whatever it is told even in user mode. The only time a CPU will actually reject an instruction is if its bonkers. Either it's an opcode that makes no sense to the CPU or, more commonly, it is an opcode that requests memory be used in some way that is flat out disallowed in virtual memory. In those cases the CPU will usually fire off an exception and force a context switch to the kernel to handle the error. It'll be up to the operating system how to proceed, but usually, except in cases of page faults, this means death to the offending process. The cases where the CPU will reject an instruction because it's plain invalid or violates memory access rules is called a "fault."
How is system call executed?
For a user most system calls are simply wrapped in simple command utilities such as chroot and mkdir and the like. But system calls proper are made by software, plain and simple. Usually how it works on the low level is dependent on the architecture being used. For "simplicity" I'll refer to x86(_64). When a system call is made, it's done by putting the parameters of the call in a series of general purpose registers in the CPU, then either signaling an interrupt or, in the case of 64-bit x86, actually using the syscall instruction. What happens then is a context switch occurs, and the CPU is switched over to kernel mode and the kernel itself is actually running now and has your system call. Meanwhile, the process that made the system call is put in the "blocked" list until the needs of the system call are met. Remember that a system call is a simple request for a service from the operating system by something in user space. Things in user space can't do a whole lot themselves in reality, and have to ask the operating system for a lot of support. While an application can do a lot with the CPU, as soon as it needs any sort of hardware support, or more memory, or less memory, it has to ask the operating system for it. For example: I wrote a text document in vi. To save, vi has to make a system call (Actually, a LOT of system calls.) to the kernel to actually write the buffer to disk. Think of system calls as being among the building blocks of the actual execution of software on *nix systems. The process will happily use CPU instructions without operating system help, but applications make constant use of hardware in some way, and to do that, they have to use instructions for the kernel, who may or may not actually GRANT the requests based on permissions or sanity of the system call, as opposed to a CPU which will MOSTLY do whatever it is told even in user mode. The only time a CPU will actually reject an instruction is if its bonkers. Either it's an opcode that makes no sense to the CPU or, more commonly, it is an opcode that requests memory be used in some way that is flat out disallowed in virtual memory. In those cases the CPU will usually fire off an exception and force a context switch to the kernel to handle the error. It'll be up to the operating system how to proceed, but usually, except in cases of page faults, this means death to the offending process. The cases where the CPU will reject an instruction because it's plain invalid or violates memory access rules is called a "fault."
What are the four major resource manager in typical operating system?
I don't think there are four resource managers in a typical OS. Usually a kernel will have: 1. A process scheduler, which will determine when which process runs on what CPU or core and for how long based on various rules often hardcoded into it. Usually how it works is based on priorities of each process (How 'important' the process is, rather, how much CPU time the process really needs every quantum.), preemption (Interrupting a process whenever an interrupt occurs.), and blocking (When a process pauses itself when it makes a request to the operating system, usually involving I/O operations, via system call or message passing.). The scheduler also handles most of the decisions on when a process is created or destroyed, since it'll need to make that call based on its own queue. 2. A memory manager, which in most operating systems will provide virtual memory and paging. It's job is to set up a protected memory system, which means no process should even see another process's memory, let alone write to it. Virtual memory is the best way to do this, as it means that every process will see a "simulated world" for itself in memory and nothing else. The operating system, and often the hardware, will transparently handle translating a process's addressing to real physical addresses in system RAM. This keeps even the buggiest of userspace programs from affecting any other process or even the running kernel itself should it misbehave. Paging is a mechanism where these little virtual memory spaces are broken up into little pieces of equal length, allowing a program to be allocated memory even in non-contiguous spaces in memory. Further, swap relies on paging support, allowing pieces of a processes memory to be stored on the hard disk when not needed if physical RAM runs low. As a memory manager is meant to protect processes from each other and the operating system from its processes, if a programtries to access memory in a way that isn't allowed, the operating system can quickly terminate the process. 3. There is also the I/O scheduler. It is also like the process scheduler in that it has to make quick on-the-fly decisions on what process gets use of something. In this case hardware, usually a disk. 4. Interprocess communication mechanisms: As a process cannot access another process in memory, the kernel does need to provide at least one avenue for processes to tell other processes what they need from each other. Usually there will be something in userspace that actually handles these transactions through the kernel. 5. Finally, driver support. All kernels need to provide some way for drivers, programs that provide communication and control of the hardware, to get the kernel to talk to the hardware. Kernels usually come in two flavors: Monolithic and micro, and one of the most importatnt and fundamental differences between the two is how their drivers work. A monolithic kernel will generally allow all drivers to become a part of it, either compiled right in or, more commonly, as loadable kernel modules. This allows drivers to talk to the kernel and their hardware directly. Microkernels, on the other hand, have only a basic process scheduler, memory manager, and IPC mechanism, and rely on userspace to provide the rest of the system, including drivers. Drivers have no direct line to the kernel but will have to end up making system calls like any user space program. This design, needless to say, is not efficient. There are also "hybrid" kernels, but generally they are still monolithic in design, but have a component or two in userspace. Drivers will almost certainly still be loadable kernel modules or part of the kernel, as most operating system designers agree, performance is better served when device drivers do not have to compete with userspace processes for kernel services.
What are the functions of the three system components in the Linux operating system?
1. There is no the Linux operating system.2. Only one component is strictly necessary to make a Linux operating system - the kernel.
What is the Difference between memory management ans device management?
Memory Management.The kernel of a computer will have full access to the system's memory and is required to allow any processes to access this memory when needed. To do this, the kernel carries out virtual addressing. Within virtual addressing it is possible to make a given physical address to appear as a virtual address, i.e. Another address. These virtual address spaces are different for different processes.The memory that is processed to access one virtual address may be different to the memory that a process accesses at the same address. These spaces allow ever program on the computer to run as if it is the only one and stops these applications from crashing each other. Virtual addressing can also be used to create virtual partitions of memory in disjointed areas. One of these areas will be reserved for the kernel and other for applications.Device Management.Device drivers, processed by the kernel, are used in order to control the peripherals that are connected to the computer. These peripherals need to be accessed by processes to perform useful functions. A list of the available devices is maintained by a kernel and is either known in advance, configured by the user or detected by the operating system at run time.Device management is a very operating system specific topic and each of the drivers is handled differently by the different kinds of kernel design. The thing that they all have in common is that the kernel is required to provide the input output to allow drivers to access their devices.These two different facilities within the kernel of a computer are used alongside process management and system calls to help the kernel carry out its role within the system.
What do you call the process where you make pastry bigger with a rolling pin?
I call that 'rolling it out'
Give an example of modular monolithic kernel?
Modular monolithic kernel example is Linux.don't need to confuse on monolithic and modular kernel. if we need to divide a single module of kernel in separate module to make handle easy we can do at the configure time of kernel but these kernel module having only in kernel space.Monolithic Kernel- single binary file- all drivers include in kernel itself.Modular kernel- Multiple files for kernel- Drivers can be loaded or unloaded into kernel using modprob command, see man page of lsmod, modprob etc when- Almost all drivers are build and linked against kernelactual mean of modular kernel in linux :some part of the system core will be located in independent files called modules that can be added to the system at run time. Depending on the content of those modules as1. only loading drivers if a device is actually found2. only load a filesystem if it gets actually requested3. only load the code for a specific (scheduling/security/whatever) policy when it should be evaluatedThose modules are still running in the kernel space and not in user space, so the kernel architecture is still monolithic.
What is the difference between a Kernel and an operating system?
An operating system, also known as an OS, is the software that makes a computer usable. The kernel is merely the "core" or lowest level of an operating system. The kernel provides numerous callable routines that allow other software to access files, display text and graphics, get input from a keyboard or mouse, and other such capabilities. The operating systems that we come across today, generally have many features which are not the necessary features to make a system work. But these features are required to make the interaction with the system easier. Such features include graphical interface, file management, process management, shell, etc. These features rely on the core part of the OS (called as kernel) to run and provide interface to the user or other application programs. It is to be realized that these features are inevitable, and only a kernel alone is of no use to the user. An operating system also includes utilities that use the kernel. For example, MS-DOS provides a program known as COMMAND.COM, which is the program that allows a human to use the operating system. Windows Explorer, the MacOS Finder, and the various UNIX shells offer similar functionality. Other OS utilities may include a file manager, a software installer, and other items that are necessary to make the computer useful (never mind some don't find computers useful in the first place :) ).
