COMP 3000 Essay 1 2010 Question 2

Question

How do the available system calls in modern versions of the Linux Kernel (2.6.30+) compare with the system calls available in the earliest versions of UNIX? How has the system call interface been expanded, and why? Focus on major changes or extensions in functionality.

Answer

A system call is a mean by which programs in the user space can access kernel services. Systems calls vary from operating system to operating system, although the underlying concepts tends to be the same. In general, a process is not supposed to be able to access the kernel directly. It can't access kernel memory and it can't call kernel functions. When the CPU prevents a process from accessing the kernel, this prevention is commonly known as, the protected mode. On the other hand, system calls are an exception to this rule. For example, older x86 processors used an interrupt mechanism to go from user-space to kernel-space, but newer processor (PentiumII+) provided instructions that optimize this transition using sysenter and sysexit instructions (Hayward, Mike. Intel P6 vs P7 system call performance. [1], December 9, 2002). All system calls are small programs built using the C programming language.

The Unix and Linux systems calls are roughly grouped into 6 major categories: file management, device management, information maintenance, process control, communications and miscellaneous calls. The miscellaneous calls are all the ones that don’t really fit in the other categories, like system calls dealing with errors. Today, the Unix and Linux operating system contains hundreds of system calls but in general, they all came from the 35 system calls that came with one of the original UNIX OS in the early 70s. In the next paragraphs, we’re going to describe the various system calls in each of the categories mentioned above, their evolution through history (major changes in functionality) and a comparison with the earliest versions of UNIX.

File Management Calls

The system calls in this group deal with every type of operation that is required to run a file system in the operating system. Create file, delete file, opening a file and closing a file are just a few examples of them and most of them hardly changed throughout the years.

chmod, chown and chdir has been available since the first original UNIX (1971) and it is still used in today’s Linux kernels. The chmod and chown calls allows the users to change the file attributes and implements security to the file system. The system call chdir allows the process to change the current working directory. In the 4th distribution of UNIX from Berkeley (4BSD), new system calls were added to be able to give more control on the file system to the applications. The call chroot allows the process to change the current root directory with one specified in a path argument. fchmod and fchdir are the same as chmod and chdir except it takes file descriptors as arguments. As of Linux kernel 2.1.81, the chown system call follows symbolic link and introduce a new system call, lchown, that does not follow symbolic links.

Another four of the original UNIX system calls are open, creat, mkdir and close. The open and creat calls allows processes to open and possibly create a file or device. Arguments flags are used to set either access modes, like O_RDONLY(read-only), to status flags, like O_APPEND(append mode). The only modifications made to the system calls were the addition of status flags where some of them are only linux-specific. The close call allows processes to close a file descriptor preventing it to be reused. No changes were made to it. mkdir allows the creation of a file directory. At that point, to delete a directory, users would need to make a series of link and unlink system calls. With Unix 4.2BSD, rmdir and solved the problem. The rename call was also added in 4.2BSD allowing processes to change the name or the location of a file.

There is also system calls used to find, access and modify files. They are ’‘read’’, ‘‘write’’, ‘‘seek’’ and ‘‘stat’’. These were all part of earliest UNIX built. The ‘‘read’’ and ‘‘write’’ system calls allows to read and write from a file (assigned to a file descriptor). The only change was in SVR4 where a write can be interrupted at anytime. The ‘‘seek’’ system calls is used to go to a specified position in a file. This calls used a 16 bit address. But this was replaced very quickly for ‘‘lseek’’ as early as SVR4. It allows the call to use 32 bit addresses. It is still used in modern Linux and Unix systems even if developers are trying to implement ‘‘lseek64’’, a system call that will use 64 bit addresses. The ‘‘stat’’ system calls allows processes to get the status of a file. With SVR4, 2 other version of that system call were created: ‘‘fstat’’ and ‘‘lstat’’. They both do the same thing except ‘‘lstat’’ give the status of symbolic links and ‘‘fstat’’ give the status of a file specified by a file descriptor. Different operating systems will output different values to represent the state of a file. Since kernel 2.5.48, the stat returned a nanoseconds field in the file’s timestamp. With the release of 4.4BSD, two new system calls called ‘‘statvfs’’ and ‘‘fstatvfs’’ were introduced to provide information about a mounted file system. They both do the same thing except fstatvfs takes file descriptors as an argument. These calls are only used in an UNIX environment. In Linux, it has ‘‘statfs’’ and ‘‘fstatfs’’ to support that same call.

The last two original UNIX system calls in this category that are still used today are link and unlink. link creates a hard link to an existing file and unlink deletes a file link’s name and possibly the file it refers to. If the name refers to a symbolic link, only the link is removed. No major changes were done to the unlink system calls but new system calls were create from link. The symlink system call was added in 4.2BSD to allow the creation of symbolic links in the file system.

In the Linux 2.6.16 build, multiple system calls were created so that the calls could deal with relative pathnames as arguments. They can easily be spotted as the system call names all finish with 'at'. Here is a sample list of the created system calls: openat, mkdirat, fchmodat, fchownat, fstatat, linkat, unlinkat, renameat and fchmodat.

Device Management Calls

The device management system calls are linked to hardware and they are mainly used to requests for devices, release devices, to logically attach a device or to detach it, get and modified device attributes and read and write to them.

Two of the most important system calls for the UNIX and Linux operating system is ‘‘mount’’ and ‘‘umount’’. These were among the few system calls available in UNIX in the 70s. The two calls allowed the operating system to load file systems on storage devices. A few changes were done to the mount system calls most of them were the creation of new mount flags to enhance performance. For example, since Linux 2.5.19, the MS_DIRSYNC flag permits the directory changes on a file system synchronous. Another Linux improvement was to provide per-process mount namespaces. This was added on the 2.4.19 kernel. If a process was created using clone() with the CLONE_NEWNS flag, the process will have a new namespace initialized to be a copy of the namespace of the process that was cloned. The ‘‘umount’’ system call unmounted the file system from the storage device. The only noteworthy change to ‘‘umount’’ was the creation of ‘‘umount2’’ in Linux 2.1.116. It is the same as ‘‘umount’’ except it allows different flags to control the operation.

The ‘‘open’’, ‘‘read’’ and ‘‘write’’ calls can also be used to access devices. As discussed in the previous section, arguments flags are used to better control the device. You would use them as if the devices were files using the appropriate flags.

With the System V Unix revision 4(SVR4) came the system call ‘‘mmap’’. This system call is used to map or unmap files or devices into memory. Once a device is mapped, the system call returns a pointer to the mapped area allowing processes to access that device. This system call is still used in a Unix environment but since Linux 2.4, Linux replaced it by the mmap2 system call. It is basically the same as mmap except for a final argument specifying the offset into a file in 4096-byte units. This enables the mapping of large files.

In version 7 of Unix, ‘‘ioctl’’ system call is used for device-specific operations that can’t be done using the standard system calls. This helps to deal with a multitude of devices. Each device drivers would provide a set of ioctl request code to allow various operations on their device. Each various request code are hardware dependent so there is no standard available for this system call.

Information Maintenance Calls

Information maintenance calls are system calls that return the computers personal information back to the user or change it completely. These type of calls can be split up into three groups get/set time or date, get/set system data and get/set process,file, or device attributes. To fully understand the difference between Linux and UNIX in regrades to system call one must explore the three sub type of information maintenance calls and see how they have changed over time.

The First sub type is Get/set of time and/or date, in Linux this can be done by a few different system call, there is: 'gettimeofday' to get the time, 'settimeofday' to set it, 'time' returns the time in seconds. The earliest versions UNIX used the system call 'stime' to interacted with time and dates. Stime could return the time and date and sets the system’s idea of the time and date by altering the seconds. 'stime' is still being used by Linux because it is successful, unlike 'settimeofday' which was created to change timezones (tz_dsttime) as well as the time but each occurrence of this field in the kernel source(apart for declaration) is a bug thus failing. (come back to)

The second sub type is get/set system data. UNIX does this by....

References

Salus, Peter H. A Quarter Century of Unix, Publisher: Addison-Wesly Professional, June 10, 1994.

Unix Programming Manual, http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html, November 3, 1971.

Linux Programmer's Manual, Linux man-pages project. http://www.kernel.org/doc/man-pages/