|
Multigrade drivers Originally, the term "driver" used in a narrow sense:
understood by the driver software module that: part of the operating system
kernel, working in a privileged mode; directly manages external device,
interacting with the controller via I / O commands computer; handles off of
the controller device; Provides application programmer - friendly interface with
logical device ekraniruya details of the low-level device management and its
data; interacts with other OS kernel modules through strictly specified
interface, which describes the format of transmitted data structure buffers,
ways to enable drivers to the operating system, how to call the driver, a set of
common I / O subsystem, which the driver can enjoy, etc. Under this definition
driver with the device controller and application embodied the idea of multi-layer
approach to software. The controller was lower layer management device that
performs the operation in terms of units and aggregates devices (such as the
movement of the drive head, pobitnuyu transfer byte for two-wire). Driver served
more complex operations, transforming, for example, addressed in terms of
numbers of cylinders, heads and sectors of the disk, in a linear sequence of
units or establishing a logical connection between two modems via telephone
network. As a result, the application has worked with the data converted to a
clear human form, files, database tables, text windows on the screen, etc.,
without going into the details of these data I / O devices. In addition, placing
the driver in the privileged treatment and the prohibition of user processes to
perform I / O operations to protect critical to the work of the OS device I / O
errors of applications and allow OS reliably monitor the separation devices and
data between users and processes . In the scheme described is not divided into
segments. In doing so, they perform tasks at various levels of complexity: as
the most primitive, for example, has just passed controller bytes for future use,
and a complex of deep protocol interface between modem or drawing on the screen
mathematical curves. Gradually, as the operating systems and the complexity of
the structure of the subsystem I / O, along with traditional drivers operating
systems have so-called higher-level drivers, which are located in the I / O
subsystem model of traditional drivers. The advent of high level drivers can be
further developed the idea of multiple I / O subsystem. Rather than concentrate
all responsibility for the device in one software module, in many cases much
better distribute them among several modules in adjacent layers of hierarchy.
Traditional drivers, which became known as hardware drivers, low-level drivers,
or drivers devices, stressing their close relationship with the managed devices
are exempt from the higher-level functions and are only low-level operations.
These low-level operations are the foundation on which you can build a set of
operations drivers higher levels. This approach increases flexibility and Scales
responsibility for the management of device-instead of a hard set of functions
concentrated in a single driver, the administrator can select the OS
functionality with a desired high level driver. If different applications to
work with different logic model of the same physical device, then quite a few
drivers in the system at the same level, working on a hardware driver. The
number of drivers in the I / O subsystem is usually not confined to any limit,
but in practice most often used between two and five levels of drivers, too many
levels could reduce the speed I / O operations. Several drivers, managers one
device, but on different levels, can be viewed as a set of individual drivers or
as a multi-driver. High-level drivers are provided for the same rules and have
the same internal interfaces, and that the hardware drivers. The only difference
is that higher-level drivers are usually not called for breaking off as interact
with the managed devices through hardware drivers. Manager manages I / O drivers
odnotipno, regardless of what level it is.
If there is a large number of drivers might have complicated relations between
them, which in turn, makes their interaction, and that this situation has led to
the standardization of internal interface I / O subsystem and providing special
envelope as manager of I / O, performing functions on the organization of the
drivers. Now, as general principles of a multi-drivers can be implemented in the
management of certain types of external devices. In vertical subsystem network
devices shown in Fig. 7.2, hardware drivers are drivers Network Adapter, which
serve as low-level canal protocols, such as Ethernet, Frame Relay, ATM and
others. These drivers perform simple functions - they organize the transfer of
personnel data between a computer network. Above them is the layer modules that
implement functions in a more intelligent network protocols-level IP and IPX,
which can make interaction with computers across networks of arbitrary topology
connection. Modules IP and IPX can also be arranged as drivers while they are in
the intermediate layer software and equipment not directly interact. Generally,
the vertical subsystem management network devices is an example of an effective
approach to multi-drivers simply because it is based on a well-thought-out seven
model for open systems OSI. And, although all seven of the OSI model is not
normally available in separate software levels, the four-level drivers often
present in the facility management of network devices. A driver layer networking
protocols is drivers transport layer protocols such as TCP / UDP, SPX and
NetBEUI, which are responsible for communications between computer networks.
Even higher the layer driver application layer protocols (Figure - http, ftp and
8MB), which provide services to end users with access to hypertext information,
archives files, and many others. In graphics subsystem management devices, such
as graphics monitors and printers, there are several levels of drivers. At the
lowest level are the hardware drivers, which enable the specific graphic adapter
or printer type, forcing them to a set of primitive graphics operations: finding
point circle, filling of color, finding characters, etc. High-level graphics
drivers built on the basis of these operations more powerful operations, such as
image scaling, image format conversion, in accordance with the possibility of
allowing devices, etc. The uppermost level subsystem is a window manager, which
creates applications for each virtual screen image as a set of windows, which
may withdraw its application image data. Manager manages windows, displaying
them in a certain area of physical screen or making them invisible, as well as
to share control of access rights. Manager windows no longer depends on the
specific graphic devices, providing high level drivers to convert data formats
withdrawal. In managing disk subsystem hardware drivers support for higher
levels of the disk as a coherent set of blocks of identical size and converts
together with the controller unit in the number of more complex address, a
number cylinder, head and sector. However, concepts such as "file" and "file
system, disk hardware drivers do not support these user-friendly software and
logical abstractions created at a higher level software file systems, which in
modern OS also formalized as a driver, only high level. A universal environment
created by the manager of I / O, allowing just one problem in OS support
multiple file systems simultaneously. To this end, a number of high level OS
drivers (the figure is drivers ufs file systems, NTFS and FAT), working with
common hardware drivers, but in their own way of organizing data storage units
and continued its drive of the file system and user application processes. For
unification of the different file systems in the I / O subsystem can be used
common driver top level, playing the role of manager of several drivers, file
systems. The figure shows an example controller VFS (Virtual File System), used
in UNIX implemented by Air System V Release 4. Not every I / O subsystem modules
are provided in the form of drivers. For example, the disk subsystem management
usually has a module as disk cache, which is used to cache disk blocks files in
RAM. Suffice specific functions do not cache design it as a driver, interacting
with other modules OS only through I / O services manager. Another module, which
more often than not formalized in a driver, a distributor of windows GUI.
Sometimes, the module is made from the OS kernel and is a custom process. Thus
was implemented Manager windows (as well as the high level graphics drivers) for
Windows NT 3.5 and 3.51, but this approach has slowed mikroyaderny graphical
operations, and in Windows NT 4.0 and higher-level controller window graphics
drivers and graphics GDI library were moved to kernel space. Hardware drivers
after the launch of I / O operations to be able to respond to the completion of
the controller set, and to this end they interact with the system off. Drivers
higher levels are not caused by aborting, and by hardware drivers or drivers
vyshelezhaschego level. Not all procedures necessary hardware drivers cause for
discontinuing, and the driver usually has a structure that stands out sections
of abandonment (Interrupt Service Routine, ISR), which is triggered when a
request from a device controller interruption. Manager abandonment can be
considered part of the subsystem I / O, as shown in Fig. 7.2, and can be
considered independent module and the OS kernel, as it serves not only to call
off sections of drivers, but also for other types of dispatch interruption. In
the Unification drivers made a great contribution UNIX operating system. It all
drivers were divided into two major classes: block-oriented (block-oriented)
drivers and Bayt targeted (character-oriented) drivers. This division is more
common than shown in Fig. 7.2 division of the vertical subsystem. For example,
graphics device drivers and drivers of network devices are Class Bayt targeted.
Flow control devices targeted drivers direct access to information stored in a
fixed size blocks, each of which has its own address. The most common external
device direct-access disk. Adresuemost blocks led to devices that direct access
is possible cached in RAM, and this greatly affects the overall organization for
the I / O block-oriented drivers. The devices, which are targeted Bayt drivers
not adresuemy and not allow the search operation, they generate or consume byte.
Examples of such devices, which are also known as a consistent access devices, a
terminal, lower printers, network adapters. Significant differences block
oriented and Bait-oriented drivers illustrates the fact that the environment
STREAMS designed only to Bait-oriented drivers and include block-oriented driver
impossible. Bait Box or orientation is a characteristic of the device, and the
driver. Obviously, if a device does not support addressed to exchange data
blocks, and can read or write a sequence of bytes, then the device and its
driver are Bayt targeted. For Bait-based devices can not be a block-oriented
driver. Device direct access to the block address is block-oriented, and for the
management of natural use of block-oriented driver. But block-oriented devices
can be managed and, using Bayt oriented driver. Thus, the disk can be seen not
only as a set of blocks, but as a set of bytes, the first of which is the first
block of disk and the last completing the last block. Physical exchanges with
the controller device is still blocks, but Bayt oriented device driver will
transform blocks in the sequence of bytes. For direct access devices often
develop a couple of drivers that the product can be treated and Bait-oriented,
and block-based interfaces, depending on the needs. Splitting all drivers at
roadblocks targeted and targeted Bayt is useful for structuring the management
subsystem ins conclusion. However, it must be borne in mind that the scheme is
simple-there are external devices, drivers who are not party to any class, such
as timer, which, on the one hand, does not contain information adresuemoy, on
the other hand, does not pose stream of bytes. The device only gives off a
signal in some points in time. UNIX operating system at the time took another
significant step to unify operations and the structuring of software I / O. In
UNIX OS devices are seen as some virtual (special) files, allowing use of a
common set of basic operations, I / O to any device regardless of their
specificity. These issues are discussed in the next section on files and file
systems. Special Files Special files, sometimes called virtual, not associated
with static data sets stored on the disk, and are comfortable presenting a
unified I / O devices. The notion of a special file to appear in the operating
system UNIX. Special file is always associated with some I / O device and submit
it for the rest of the operating system and application processes in the form of
unstructured set of bytes. With special file can be the same as normal, that is,
open, read from a certain number of bytes or write a certain number of bytes,
and after operations close. It uses the same system calls as to work with a
regular file: open, create, read, write and close. Thus, in order to put on
Alphanumeric terminal, which is a special file / dev/tty3, the "Hello, friends!
" Suffice to open the file using a system called open: fd = open ( "/ de/tty3."
2) You can then display with System Call write: write (fd, "Hello, friends!" .
15) For direct access devices, it makes sense to index the current situation in
the file, which can be controlled through a system called lseek. Obviously, the
presentation device in a file and use for a device file management system calls,
in many cases, not only enables a simple operation. Traditionally, special files
are stored in the directory / dev, although nothing prevents them to create any
directory file system. When a new device and a new driver to the system
administrator can create a new account by using the mknod. For example, the
following command creates a block-oriented special file: mknod / dev/dsk/sc4d2s3
b 32 33
|
OwlCom
Software
