[FreeBSD] Design Overview of FreeBSD

 

 

 

The kernel 

https://www.researchgate.net/publication/239441788/figure/fig20/AS:669527914344467@1536639302321/FreeBSD-kernel-I-O-overview-Adapted-from-MCKUSICK1996.png

 

 

 

 

커널이란?

• The kernel is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware (e.g., CPU, keyboard, monitor, disks, network links) and software constructs (e.g., filesystem, network protocols).
• The kernel provides the basic system facilities; it creates and manages processes and provides functions to access the filesystem and communication facilities.
• These functions, called system calls, appear to user processes as library subroutines. These system calls are the only interface that processes have to these facilities.

• A kernel, in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services. Through much of the 1980s, research operating systems—such as Tunis [Ewens et al., 1985], Chorus [Rozier et al., 1988], Mach [Accetta et al., 1986], and the V Kernel [Cheriton, 1988]—attempted to make this division of functionality into more than just a logical one.
• Services such as filesystems and networking protocols were implemented as client application processes of the nucleus or kernel. These micro-kernels largely failed because of the high overhead of transitioning between kernel processes.

 

• The FreeBSD kernel is not partitioned into multiple processes. This basic design decision was made in the earliest versions of UNIX. The first two implementations by Ken Thompson had no memory mapping and thus made no hardware-enforced distinction between user and kernel space [Ritchie, 1988]. A message-passing system could have been implemented as readily as the actually implemented model of kernel and user processes.
• The monolithic kernel was chosen for simplicity and performance. And the early kernels were small; the inclusion of facilities such as networking into the kernel has increased its size, although the kernel is still small compared to many of the applications that run on it.

 

• Users ordinarily interact with the system through a command-language interpreter, called a shell, and through additional user application programs. Such programs and the shell are implemented with processes rather than being part of the kernel. (커널과 분리된 다른 programs) Details of such programs are beyond the scope of this book, which instead concentrates almost exclusively on the kernel.

 

 

 

커널의 구성 요소

Kernel Organization

View the organization of the FreeBSD kernel in two ways:

1. 1As a static body of software, categorized by the functionality offered by the modules that make up the kernel
2. By its dynamic operation, categorized according to the services provided to users

 

• The largest part of the kernel implements the system services that applications access through system calls. In FreeBSD, this software has been organized according to the following
  • Basic kernel facilities: timer and system-clock handling, descriptor management, and process management
  • Security features: conventional UNIX model, but also sandboxing, virtualization, event auditing, and cryptographic services
  • Memory-management support: paging and swapping
  • Generic system interfaces: the I/O, control, and multiplexing operations performed on descriptors
  • Filesystems: files, directories, pathname translation, file locking, and I/O buffer management
  • Terminal-handling support: the pseudo-terminal interface and terminal line disciplines
  • Interprocess-communication facilities: sockets
  • Support for network communication: communication protocols and generic network facilities, such as routing

 

• Most of the software in these categories is machine independent and is portable across different hardware architectures.
• The machine-dependent aspects of the kernel are isolated from the mainstream code. In particular, none of the machine-independent code contains conditional code for specific architectures. When an architecture-dependent action is needed, the machine-independent code calls an architecture-dependent function that is located in the machine-dependent code. The software that is machine dependent includes the following
  • Low-level system-startup actions
  • Trap and fault handling 
  • Low-level manipulation of the run-time context of a process
  • Configuration and initialization of hardware devices
  • Run-time support for I/O devices