Return to Answer

This hints at the idea that a "kernel" design type is not what makes the UNIX standard or what defines a unix-like OS. This is evidenced by the fact that many unix-like OSes may have either a monolithic kernel or a microkernel - monolithic was the classical design type for UNIX. In fact, even within pure UNIXes, HPUX has a monolithic kernel whereas AIX uses a microkernel. This debate about design is about performance and is not related to Unix ancestry or identity. On the other hand, there is a traditional conceptual approach to providing services to software, dealing with file systems etc. under UNIX/unix-like operating systems.

This hints at the idea that a "kernel" design type is not what makes the UNIX standard or what defines a unix-like OS. This is evidenced by the fact that many unix-like OSes may have either a monolithic kernel or a microkernel - monolithic was the classical design type for UNIX. In fact, even within pure UNIXes, HPUX has a monolithic kernel whereas AIX uses a microkernel. This debate about design is about performance and is not related to Unix ancestry or identity. On the other hand, there is a traditional conceptual approach to providing services to software, dealing with file systems etc. under UNIX/unix-like operating systems.

If you're interested with the different implementations of kernels in unix-like operating systems, you can take a look the the FreeBSD implementation(4.4BSD) or at the Mach kernel or look at this comparison of their features.

This hints at the idea that a "kernel" design type is not what makes the UNIX standard or what defines a unix-like OS. This is evidenced by the fact that many unix-like OSes may have either a monolithic kernel or a microkernel - monolithic was the classical design type for UNIX. In fact, even within pure UNIXes, HPUX has a monolithic kernel whereas AIX uses a microkernel. This debate about design is about performance and is not related to Unix ancestry or identity.

Here are some excerpts from Mr Bach's classic book (1986) which discuss the foundations of the UNIX System V kernel:

However, they [application subsystems and programs] all use lower-level services ultimately provided by the kernel, and they avail themselves of those services via the set of system calls. There are about 64 systems calls in System V, of which fewer than 32 are used frequently. They have simple options that make them easy to use but provide the user with a lot of power. The set of system calls and the internal algorithms that implement them form the body of the kernel[...]

[...] its two major components are the file subsystem and the process subsystem.

Files are organized into file systems, which are treated as logical devices; a physical device such as a disk can contain several logical devices (file systems). Each file system has a superblock that describes the structure and contents of the file system, and each file in a file system is described by an inode that gives the attributes of the file. System calls that manipulate files do so via inodes. [and the buffer pool]

[...] There are two versions of the inode: the disk copy that stores the inode information when the file is not in use and the in-core copy that records information about active files.

The execution of user processes on UNIX systems is divided into two levels: user and kernel. When a process executes a system call, the execution mode of the process changes from user mode to kernel mode: the operating system executes and attempts to service the user request[...]

[...] the philosophy of the UNIX system is to provide operating system primitives that enable users to write small, modular programs that can be used as building blocks to build more complex programs. One such primitive visible to shell users is the capability to redirect I/O.

[...] In addition to servicing system calls, the kernel does general bookkeeping for the user community, controlling process scheduling, managing the storage and protection of processes in main memory, fielding interrupts, managing files and devices and taking care of system error conditions.

If you're interested with the different implementations of kernels in unix-like operating systems, you can also take a look the the FreeBSD implementation(4.4BSD) or at the Mach kernel or look at this comparison of their features.

This hints at the idea that a "kernel" design type is not what makes the UNIX standard or what defines a unix-like OS. This is evidenced by the fact that many unix-like OSes may have either a monolithic kernel or a microkernel - monolithic was the classical design type for UNIX. In fact, even within pure UNIXes, HPUX has a monolithic kernel whereas AIX uses a microkernel. This debate about design is about performance and is not related to Unix ancestry or identity. On the other hand, there is a traditional conceptual approach to providing services to software, dealing with file systems etc. under UNIX/unix-like operating systems.

Insofar as the kernel itself is concerned, you'll often find a conceptual diagram such as this one to illustrate what a UNIX kernel traditionally was:

There's more to this than meets the eyes really. For instance, Mac OSX is UNIX03 certified but do you see it connected to any of the pure UNIXes (in red mostly)?

Insofar as the kernel itself is concerned, you'll often find a conceptual diagram such as this one to illustrate what a UNIX kernel traditionally was about:

If you're interested with the different implementations of kernels in unix-like operating systems, you can take a look the the FreeBSD implementation(4.4BSD) or at the Mach kernel or look at this comparison of their features.

There's more to this than meets the eyes really. For instance, Mac OSX is UNIX03 certified but do you see it connected to any of the pure UNIXes (in red mostly)?