This action might not be possible to undo. Are you sure you want to continue?
Diwaker Singh Reg.Id.10808015
B.Tech-MBA (CSE), Lovely Professional University Punjab
Abstract- This term paper aims to
provide an overview of the concepts of device management in UNIX operating system. It deals with the meaning of the term device management, how device management is done in case of UNIX operating system and various terms and concepts related with device management in UNIX operating system.
driver translates between the hardware commands understood by the device and the stylized programming interface used by the kernel. The driver layer helps keep the kernel reasonably device independent. In most cases, device drivers are part of the kernel; they are not user processes. However, a driver can be accessed both from within the kernel and from user space. User-level access to devices is usually through special device files that live in the /dev directory. The kernel maps operations on these files into calls to the code of the driver. With the remarkable pace at which new hardware is developed, it is practically impossible to keep mainline OS distributions up to date with the latest hardware. Ergo, you will occasionally need to add a device driver to your system to support a new piece of hardware. Device drivers are system specific, and they are often specific to a particular range of kernel revisions as well. Drivers for other operating systems (e.g., Windows) will not work. This should be kept in mind while purchasing a new hardware. In addition, devices vary in their degree of compatibility and functionality when used with various Linux distributions, so it’s wise to pay some attention to the results other sites have
INTRODUCTION This term paper deals with the main heading “Device management in UNIX” .In this term paper I am explaining about the basic meaning of the term device management? The second part contains the information about basic terms related to device management and explanation of different concepts that are used for device management in case of UNIX operating System. It gives a brief idea of how an operating system interact with external devices.
WHAT IS IT??
A device driver is a program that manages the system’s interaction with a particular type of hardware. The
obtained with any hardware we are considering.
EXAMPLE OF DEVICE DRIVER INTERFACE
DEVICE FILES AND DEVICE NUMBERS Most devices have a corresponding file in /dev; network devices are notable exceptions on modern operating systems. Complex servers may support hundreds of devices. Solaris handles this complexity quite nicely by using a separate subdirectory of /dev for each type of device: disk, cd-rom, terminal, etc. By virtue of being device files, the files in /dev each have a major and minor device number associated with them. The kernel uses these numbers to map devicefile references to the corresponding driver. The major device number identifies the driver with which the file is associated (in other words, the type of device). The minor device number usually identifies which particular instance of a given device type is to be addressed. The minor device number is sometimes called the unit number. You can see the major and minor number of a device file with ls -l: linux$ ls -l /dev/sda DEVICE MANAGEMENT ORGANISATION brw-rw---- 1 root disk 8, 0 Jul 13 01:38 /dev/sda This example shows the first SCSI disk on a Linux system. It has a major number of 8 and a minor number of 0.
REPRESENTATION DEVICES IN UNIX
All devices are represented by files called special files that are located in /dev directory. Thus, device files and other files are named and accessed in the same way. A 'regular file' is just an ordinary data file in the disk. A 'block special file' represents a device with characteristics similar to a disk (data transfer in terms of blocks). A 'character special file' represents a device with characteristics similar to a keyboard (data transfer is by stream of bits in sequential order).
The minor device number is sometimes used by the driver to select or enable certain characteristics particular to that device. For example, a tape drive can have one file in /dev that rewinds the drive automatically when it is closed and another file that does not. The driver is free to interpret the minor device number in whatever way it wants. Look up the man page for the driver to determine what convention it’s using. There are actually two primary types of device files: block device files and character device files. A block device is read or written one block (a group of bytes, usually a multiple of 512) at a time; a character device can be read or written one byte at a time. Disks and tapes lead dual lives; terminals and printers do not. Device drivers present a standard interface to the kernel. Each driver has routines for performing some or all of the following functions:
part of the driver. To perform an unusual operation that doesn’t have a direct analog in the filesystem model (for example, ejecting a floppy disk), a program can use the ioctl system call to pass a message directly from user space into the driver. DEVICE FILE CREATION Device files can be created manually with the mknod command, with the syntax mknod filename type major minor where filename is the device file to be created, type is c for a character device or b for a block device, and major and minor are the major and minor device numbers. If you are manually creating a device file that refers to a driver that’s already present in your kernel, check the documentation for the driver to find the appropriate major and minor device numbers. Under Linux, the udev system dynamically manages the creation and removal of device files according to the actual presence (or absence) of devices. The udevd daemon listens for messages from the kernel regarding device status changes. Based on configuration information in /etc/udev and /lib/udev, udevd can take a variety of actions when a device is discovered or disconnected. By default, it just creates device files in /dev. On Solaris systems, /dev is actually composed of symbolic links to files in the /devices directory, which is a separate filesystem. The Device File System (devfs) manages the device files in /devices. These files are created automatically at boot time by devfsadmd, which continues to run after boot to handle update notifications from the kernel. Administrators can use devfsadm to
It is sometimes convenient to implement an abstraction as a device driver even when it controls no actual device. Such phantom devices are known as pseudo-devices. For example, a user who logs in over the network is assigned a PTY (pseudoTTY) that looks, feels, and smells like a serial port from the perspective of high-level software. This trick allows programs written in the days when everyone used a terminal to continue to function in the world of windows and networks. /dev/zero, /dev/null, and /dev/random are some other examples of pseudo-devices. When a program performs an operation on a device file, the kernel intercepts the reference, looks up the appropriate function name in a table, and transfers control to the appropriate
tweak this process, but most administrators will not need to use it. The HP-UX kernel creates devices files at boot time. If new devices are attached later, administrators must create the device files manually by running the mksf, insf, and mknod commands. The smh tool also incorporates a limited interface for viewing device information. In AIX, the cfgmgr command runs at boot time to configure devices and to install drivers for devices that weren’t formerly present. It prints warnings for any devices for which the software or drivers are not installed. Once a device is detected, AIX remembers it by placing an identifier in the Object Data Manager. cfgmgr creates files in /dev for devices that are successfully detected and initialized. Given the existence of these various tools for automating the creation of device files, system administrators running current releases of UNIX and Linux should never need to manually manage device files with mknod.
/dev/rdsk/dks0d3s0). However, an r does not always imply a raw device file. Serial device files are usually named tty followed by a sequence of letters that identify the interface the port is attached to. TTYs are sometimes represented by more than one device file; the extra files usually afford access to alternative flow control methods or locking protocols. The names of tape devices often include not only a reference to the drive itself but also an indication of whether the device rewinds after the tape device is closed. Each vendor has a different scheme. The naming conventions for the files that represent hard disks and SSDs are rather complex on most systems. CUSTOM KERNELS VS LOADABLE MODULES
NAMING CONVENTIONS FOR DEVICES Naming conventions for devices are somewhat random. They are often holdovers from the way things were done under UNIX on a DEC PDP-11, as archaic as that may sound in this day and age. For devices that have both block and character identities, the character device name is usually prefaced with the letter r for “raw” (e.g., /dev/da0 vs. /dev/rda0). An alternative convention is to store character device files in a subdirectory that has a name that starts with r (e.g., /dev/dsk/dks0d3s0 vs.
When the system is installed, it comes with a generic kernel that’s designed to run most applications on most hardware. The generic kernel includes many different device drivers and option packages. Some drivers may also be dynamically inserted into the running kernel. On Linux, the udev system can also manage real-time device changes, such as the insertion of a USB device. There are various schools of thought on whether production servers should have custom-built kernels. Although there is some potential for performance gains, especially in embedded systems without much memory, the manageability trade-off for patching and system upgrades is usually a deal breaker. Unless there’s a legitimate need to wring every last ounce of performance out of the system, we recommend using the vendor’s stock kernel.
When it comes to kernel device support, the wise administrator is usually also the laziest. Use the dynamic module approach whenever possible. Avoid building accustom kernel unless it is strictly necessary. On Linux systems, most USB devices can be attached with no administrator intervention.
 www.programmar.com  www.latrobe.edu.au  UNIX and Linux System Administration handbook by Nemeth, Snyder, Hein and Whaley  Operating system principles by silberchatz and Galvin
CONCLUSION From the above text we concluded that UNIX uses device drivers to interact with the external devices. Every connected external device has its own device driver. Device Driver is software which acts as interface between the UNIX kernel and the device. These Device drivers may be of three types I/P device drivers, O/P device driver or I/P device driver. The device manger manages the interaction between the operating system and the device. It creates a list of all the connected device and using this list it controls the information flow between operating system and external device.
ACKNOWLEDGMENT I Diwaker Singh Student of B. Tech.MBA (CSE) would like to thank my teacher for the corresponding subject that is Ms. Neha Bhateja for her guidance during the preparation of this term paper. This term paper has surely enhanced my knowledge. I would also like to thank my friends who helped me in gathering information about the topic.
REFERENCES www.wikipedia.com  www.answers.com  www.cs.utsa.edu
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.