In Linux,shared libraries perf

Answer:There are a number of reasons for keeping functionality in shared libraries rather than in the kernel itself.These include:Reliability. Kernel-mode programming is inherently higher risk than

user-mode programming.If the kernel is coded correctly so that protection between processes is enforced,then an occurrence of a bug in a user-mode library is likely to affect only the currently

executing process,whereas a similar bug in the kernel could conceivably bring down the entire operating system. Performance.Keeping as much functionality as possible in user-mode shared libraries helps performance in two ways.First of all,it reduces physical memory consumption:kernel memory is non-pageable,so every kernel function is permanently resident

in physical memory,but a library function can be paged in from disk on demand and does not need to be physically present all of the time.Although the library function may be resident in many processes at once,page sharing by the virtual memory system means that at most once it is only loaded into physical memory. Second,calling a function in a loaded library is a very fast oper-

ation,but calling a kernel function through a kernel system service call is much more expensive.Entering the kernel involves changing the CPU protection domain,and once in the kernel,all of the arguments supplied by the process must be very carefully checked for correctness:the kernel cannot afford to make any assumptions about the validity of the arguments passed in,whereas a library function might reasonably do so.Both of these

factors make calling a kernel function much slower than calling the same function in a library. Manageability.Many different shared libraries can be loaded by an application.If new functionality is required in a running system, shared libraries to provide that functionality can be installed without interrupting any already-running processes.Similarly, existing shared libraries can generally be upgraded without requiring any system down time.Unprivileged users can create

shared libraries to be run by their own programs.All of these attributes make shared libraries generally easier to manage than kernel code. There are,however,a few disadvantages to having code in a shared library.There are obvious examples of code which is completely unsuitable for implementation in a library,including low-level functionality such as device drivers or file-systems.In general,services shared around the entire system are better implemented in the kernel if they are performance-critical,since the alternative-running the shared service in a separate process and communicating with it through interprocess communication-requires two context switches for every service requested by a process.In some cases,it may be appropriate to prototype a service in user-mode but implement the final version as a kernel

routine.Security is also an issue.A shared library runs with the privileges of the process calling the library.It cannot directly access any resources inaccessible to the calling process,and the calling process has full access to all of the data structures maintained by the shared library.If the

service being provided requires any privileges outside of a normal process's,or if the data managed by the library needs to be protected from normal user processes,then libraries are inappropriate and a separate server process(if performance permits) or a kernel implementation is required.