Block devices are hardware devices distinguished by the random (that is, not necessarily sequential) access of fixed-size chunks of data, called blocks. The most common block device is a hard disk, but many other block devices exist, such as floppy drives, CD-ROM drives, and flash memory. Notice how these are all devices on which you mount a filesystemfilesystems are the lingua franca of block devices.
The other basic type of device is a character device. Character devices, or char devices, are accessed as a stream of sequential data, one byte after another. Example character devices are serial ports and keyboards. If the hardware device is accessed as a stream of data, it is implemented as a character device. On the other hand, if the device is accessed randomly (nonsequentially), it is a block device.
Basically, the difference comes down to whether the device accesses data randomlyin other words, whether the device can seek to one position from another. As an example, consider the keyboard. As a driver, the keyboard provides a stream of data. You type "fox" and the keyboard driver returns a stream with those three letters in exactly that order. Reading the letters out of order, or reading any letter but the next one in the stream, makes little sense. The keyboard driver is thus a char device; the device provides a stream of characters that the user types onto the keyboard. Reading from the keyboard returns a stream first with f, then o, then x, and ultimately end of file (EOF). When no keystrokes are waiting, the stream is empty. A hard drive, conversely, is quite different. The hard drive's driver might ask to read the contents of one arbitrary block and then read the contents of a different block; the blocks need not be consecutive. Therefore, the hard disk's data is accessed randomly, and not as a stream, and thus the hard disk is a block device.
Managing block devices in the kernel requires more care, preparation, and work than managing character devices. Character devices have only one positionthe current onewhereas block devices must be able to navigate back and forth between any location on the media. Indeed, the kernel does not have to provide an entire subsystem dedicated to the management of character devices, but block devices receive exactly that. Such a subsystem is a necessity partly because of the complexity of block devices. A large reason, however, for such extensive support is that block devices are quite performance sensitive; getting every last drop out of your hard disk is much more important than squeezing an extra percent of speed out of your keyboard. Furthermore, as you will see, the complexity of block devices provides a lot of room for such optimizations. The topic of this chapter is how the kernel manages block devices and their requests. This part of the kernel is known as the block I/O layer. Interestingly, revamping the block I/O layer was the primary goal for the 2.5 development kernel. This chapter covers the all-new block I/O layer in the 2.6 kernel.
http://www.tldp.org/LDP/tlk/dd/drivers.html
Linux maps the device special file passed in system calls (say to mount a file system on a block device) to the device's device driver using the major device number and a number of system tables, for example the character device table, chrdevs .
Administrators set up device special files with the mknod command, supplying file type (block or character) and major and minor numbers. The mknod command invokes the mknod system call to create the device file. For example, in the command line mknod /dev/ttyl3 c 2 13
"/dev/ttyl3" is the file name of the device, c specifies that it is a character special file (b specifies a block special file), 2 is the major number, and 13 is the minor number. The major number indicates a device type that corresponds to the appropriate entry in the block or character device switch tables, and the minor number indicates a unit of the device. If a process opens the block special file "/dev/dskl" and its major number is 0, the kernel calls the routine gdopen in entry 0 of the block device switch table (Figure 10.2); if a process reads the character
File Subsystem
Figure 10.1. Driver Entry Points
Switch Table
As with any UNIX os,device files are located in the /dev directory in the
root file system.Device files represent the user-level process "handle" into
the device drivers that control various hardware devices on the system.The device drivers are each assigned a major number is an offset into one of two tables,known as the switch tables,that define the operations that permissible on the devices.We have 2 switch tables:
1.for character devices
2.for block devices.
As we know,it's possible to have a single device with both a character device file and a block device file associated with it,but those operations that are supported are different,and thus the code to perform those operations is also different.
Each device special file in Tru64 UNIX is assigned a unique 32-bit device number(dev_t in <sys/types.h>)that consists of the combination of the major and minor numbers.
Major number:for any device special file is an offset into the bloc or character switch table.This is how the os determines which driver to associate with that device.
Minor number:a driver specific number that the driver uses to find a particular device of that class.
A device driver is a piece of software that operates or controls a particular type of device. On modern,monolithic kernel operating systems these are typically part of the kernel. Many monolithic kernels, including Linux, have a modular design, allowing for executable modules to be loaded at runtime. Device drivers commonly utilize this feature, although nothing prevents the device drivers to be compiled into the kernel p_w_picpath.
A device file is an interface for a device driver that appears in a file system as if it were an ordinary file. In Unix-like operating systems, these are usually found under the /dev directory and are also called device nodes. A device file can represent character devices, which emit a stream data one character at a time, or block devices which allow random access to blocks of data.
Device nodes are created by the mknod system call. The kernel resource exposed by the device node is identified by a major and minor number. Typically the major number identifies the device driver and the minor number identifies a particular device the driver controls.
What the device file appears to contain depends on what the device drivers exposes through the device file. For instance, the character device file which represents the mouse, /dev/input/miceexposes the movement of the mouse as a character stream, whereas the block device file representing a hard disk, such as /dev/sda, exposes the addressable regions of memory of the device. Some devices files also take input, allowing user-space applications to communicate with the device by writing to its device file.
In Unix-like operating systems "Everything is a file". In accordance to this principle, device files are the file system representation of the devices connected to the computer. Their content depends on what the device drivers exposes through them. For instance, the character device which represents the mouse,/dev/input/mice exposes the movement of the mouse as a character stream, whereas the block device representing a hard disk, such as /dev/sda1, exposes the addressable regions of memory
The device file is the interface between programs and the device driver. The device driver is in the kernel; the programs (applications) are in user space. The way a program can access the driver in the kernel is via the appropriate device special file
(File system)Some file systems are used on local data storage devices;[1] others provide file access via a network protocol (for example, NFS,[2] SMB, or 9P clients). Some file systems are "virtual", in that the "files" supplied are computed on request (e.g. procfs) or are merely a mapping into a different file system used as a backing store. The file system manages access to both the content of files and the metadata about those files.
File Descriptor
In simple words, when you open a file, the operating system creates an entry to represent that file and store the information about that opened file. So if there are 100 files opened in your OS then there will be 100 entries in OS (somewhere in kernel). These entries are represented by integers like (...100, 101, 102....). This entry number is the file descriptor. So it is just an integer number that uniquely represents an opened file in operating system. If your process opens 10 files then your Process table will have 10 entries for file descriptors.
Similarly when you open a network socket, it is also represented by an integer and it is called Socket Descriptor. I hope you understand.
Introduction to system concepts – overview of file subsystem
The internal representation of the file is in the form of iNode. This inode contains the information about the file such as its layout on the disk, its owner, its access permissions and last accessed time.
This inode is short form for index node. Every file has one inode. The inodes of all the files on the system are stored in inode table. When we create a new file a new entry in the inode table is created.
The kernel contain two data structures file table and user file descriptor table. The file table is global table at the kernel level but the user file descriptor table s for every process. When a process creates a file or opens a file the entry for that is made in both the tables.
The information about the current state of the file is maintained in the file table. For example if the file is being written the information about the current cursor position is kept in the file table. This file table also checks whether the accessing process has access to that file or not.
The user file descriptor table keeps a track of all the files opened by the processes and what are the relationships between these files.
File descriptors for a single process, file table and inode table. Note that multiple file descriptors can refer to the same file table entry (e.g., as a result of the dup system call)[3]:104 and that multiple file table entries can in turn refer to the same inode (if it has been opened multiple times; the table is still simplified because it represents inodes by file names, even though an inode can havemultiple names). File descriptor 3 does not refer to anything in the file table, signifying that it has been closed.
In the traditional implementation of Unix, file descriptors index into a per-process file descriptor tablemaintained by the kernel, that in turn indexes into a system-wide table of files opened by all processes, called the file table. This table records the mode with which the file (or other resource) has been opened: for reading, writing, appending, reading and writing, and possibly other modes. It also indexes into a third table called theinode table that describes the actual underlying files
To perform input or output, the process passes the file descriptor to the kernel through a system call, and the kernel will access the file on behalf of the process. The process does not have direct access to the file or inode tables.
Hear it from the Horse's Mouth : APUE (Richard Stevens).
To the kernel, all open files are referred to by File Descriptors. A file descriptor is a non-negative number.
When we open an existing file or create a new file, the kernel returns a file descriptor to the process. The kernel maintains a table of all open file descriptors, which are in use. The allotment of file descriptors is generally sequential and they are alloted to the file as the next free file descriptor from the pool of free file descriptors. When we closes the file, the file descriptor gets freed and is available for further allotment.
See this p_w_picpath for more details :
An inode is an artifact of a particular file-system and how it manages indirection. A "traditional *ix" file-system uses this to link together files into directories, and even multiple parts of a file together. That is, an inode represents a physical manifestation of the file-system implementation.
On the other hand, a file descriptor is an opaque identifier to an open file by the Kernel. As long as the file remains open that identifier can be used to perform operations such as reading and writing. The usage of "file" here is not to be confused with a general "file on a disk" - rather a file in this context represents a stream and operations which can be performed upon it, regardless of the source.
A file descriptor is not related to an inode, except as such may be used internally by particular [file-system] driver. A number of commonly opened files (e.g. sockets and special devices) do not even have inodes!
A disk can be partitioned into a no. of file systems.
An administrator can leave a partition mounted or unmounted and can make it read only/read write
Partition od Device and major number
Storage devices managed by the sd driver are identified internally by a collection of major device numbers and their associated minor numbers. The major device numbers used for this purpose are not in a contiguous range. Each storage device is represented by a major number and a range of minor numbers, which are used to identify either the entire device or a partition within the device. There is a direct association between the major and minor numbers allocated to a device and numbers in the form of sd<letter(s)><optional number(s)>. Whenever the sd driver detects a new device, an available major number and minor number range is allocated. Whenever a device is removed from the operating system, the major number and minor number range is freed for later reuse.
When we want to read or write a file, we identify the file with the file descriptor that was returned byopen() or create() function call, and use it as an argument to either read() or write().
It is by convention that, UNIX System shells associates the file descriptor 0 with Standard Input of a process, file descriptor 1 with Standard Output, and file desciptor 2 with Standard Error.
File descriptor ranges from 0 to OPEN_MAX.
For more information, go through 3rd chapter of APUE Book.
BIOS
The BIOS (/ba.s/, an acronym for Basic Input/Output System and also known as the System BIOS, ROM BIOS or PC BIOS) is a type offirmware used to perform hardware initialization during the bootingprocess (power-on startup) on IBM PC compatible computers, and to provide runtime services for operating systems and programs.[1] The BIOS firmware is built into personal computers (PCs), and it is the first software they run when powered on. The name itself originates from the Basic Input/Output System used in the CP/M operating system in 1975.[2][3] Originally proprietary to the IBM PC, the BIOS has beenreverse engineered by companies looking to create compatible systems and the interface of that original system serves as a de factostandard.
Data Buffer
In computer science, a data buffer (or just buffer) is a region of a physical memory storage used to temporarily store data while it is being moved from one place to another.
Typically, the data is stored in a buffer as it is retrieved from an input device (such as a microphone) or just before it is sent to an output device (such as speakers). However, a buffer may be used when moving data between processes within a computer. This is comparable to buffers in telecommunication. Buffers can be implemented in a fixed memory location in hardware—or by using a virtual data buffer in software, pointing at a location in the physical memory. In all cases, the data stored in a data buffer are stored on a physical storage medium. A majority of buffers are implemented in software, which typically use the faster RAM to store temporary data, due to the much faster access time compared with hard disk drives. Buffers are typically used when there is a difference between the rate at which data is received and the rate at which it can be processed, or in the case that these rates are variable, for example in a printer spooleror in online video streaming.
Superblock
A superblock is a record of the characteristics of a filesystem, including its size, the block size, the empty and the filled blocks and their respective counts, the size and location of the inode tables, the disk block map and usage information, and the size of the block groups.
The term filesystem can refer to an entire hierarchy of directories, or directory tree, that is used to organize files on a computer system. On Unix-like operating systems, the directories start with the root directory (designated by a forward slash), which contains a series of subdirectories, each of which, in turn, contains further subdirectories, etc. A variant of this definition is the part of the entire hierarchy of directories (or of the directory tree) that is located on a single disk or partition. A partition is a logically independent section of a hard disk drive (HDD) that contains a single type of filesystem.
An inode is a data structure on a filesystem on a Unix-like operating system that stores all the information about a file except its name and its actual data. A data structure is a way of storing data so that it can be used efficiently; different types of data structures are suited to different types of applications, and some are highly specialized for specific types of tasks.
A request to access any file requires access to the filesystem's superblock. If its superblock cannot be accessed, a filesystem cannot be mounted (i.e., logically attached to the main filesystem) and thus files cannot be accessed. Any attempt to mount a filesystem with a corrupted or otherwise damaged superblock will likely fail (and usually generate an error message such as can not read superblock).
Line Disciplines
provide an elegant mechanism that lets you use the same serial level driver to run different technologies.The low-level driver and the tty driver handle the transfer of data to and from the hardware.while line disciplines are responsible for processing the data and transferring it between kernel and user space.
ine disciplines also implement network interfaces over serial transport protocols. For example, line disciplines that are part of the Point-to-Point Protocol (N_PPP) and the Serial Line Internet Protocol (N_SLIP) subsystems, frame packets, allocate and populate associated networking data structures, and pass the data on to the corresponding network protocol stack. Other line disciplines handle Infrared Data (N_IRDA) and the Bluetooth Host Control Interface (N_HCI).
The serial subsystem supports 17 standard line disciplines. The default line discipline that gets attached when you open a serial port is N_TTY, which implements terminal I/O processing. N_TTY is responsible for "cooking" characters received from the keyboard. Depending on user request, it maps the control character to newline, converts lowercase to uppercase, expands tabs, and echoes characters to the associated VT. N_TTY also supports a raw mode used by editors, which leaves all the preceding processing to user applications.
tcsetattr()
#include<termios.h>
int tcsetattr(int fd, int optional_actions, const struct termios *termios_p);
tcsetattr函数用于设置终端参数。函数在成功的时候返回0，失败的时候返回-1，并设置errno的值。参数fd为打开的终端文件描述符，参数optional_actions用于控制修改起作用的时间，而结构体termios_p中保存了要修改的参数。optional_actions可以取如下的值。
TCSANOW：不等数据传输完毕就立即改变属性。
TCSADRAIN：等待所有数据传输结束才改变属性。
TCSAFLUSH：等待所有数据传输结束,清空输入输出缓冲区才改变属性。
错误信息：
EBADF：非法的文件描述符。
EINVAL：参数optional_actions使用了非法值，或参数termios中使用了非法值。
ENCTTY：非终端的文件描述符。
http://pubs.opengroup.org/onlinepubs/009695399/functions/tcsetattr.html
e.g.tcsetattr(0,TCSAFLUSH,&newtty);
read(0,buf,sizeof(buf))
0 is standard input
At the file descriptor level, stdin is defined to be file descriptor 0, stdout is defined to be file descriptor 1; and stderr is defined to be file descriptor 2. See this.
ioctl()
ioctl是设备驱动程序中对设备的I/O通道进行管理的函数。所谓对I/O通道进行管理，就是对设备的一些特性进行控制，例如串口的传输波特率、马达的转速等等。
http://blog.csdn.net/gemmem/article/details/7268533
http://man7.org/linux/man-pages/man2/ioctl.2.html
Raw and Canonical
Cooked mode is a mode of a terminal or pseudo terminal character device in Unix-like systems in which data is preprocessed before being given to a program. In this mode the system interprets special characters such as backspace, delete and other control characters such as Control-C and Control-D. The precise definition of what constitutes a cooked mode is operating system-specific.[1] The other mode is “raw mode”, also called delimiterless input, in which the data is given as-is to the program, and the system does not interpret any of the special characters.
For example, if “ABC<Backspace>D” is given as an input to a program through a terminal character device in cooked mode, the program gets “ABD”. But, if the terminal is in raw mode, the program gets the characters “ABC” followed by the Backspace character and followed by “D”. In cooked mode, the terminal line discipline processes the characters “ABC<Backspace>D” and presents only the result (“ABD”) to the program.
Technically, the term “cooked mode” should be associated only with streams that have a terminal line discipline, but generally it is applied to any systemthat does some amount of preprocessing.[2]
cbreak mode[edit]
cbreak mode (sometimes called rare mode) is a mode between raw mode and cooked mode. Unlike cooked mode it works with single characters at a time, rather than forcing a wait for a whole line and then feeding the line in all at once. Unlike raw mode, keystrokes like abort (usually Control-C) are still processed by the terminal and will interrupt the process.
From a programming point of view, a terminal device had transmit and receive baud rates, "erase" and "kill" characters (that performed line editing, as explained), "interrupt" and "quit" characters (generatingsignals to all of the processes for which the terminal was a controlling terminal), "start" and "stop" characters (used for modem flow control), an "end of file" character (acting like a carriage return except discarded from the buffer by the read() system call and therefore potentially causing a zero-length result to be returned) and various basic mode flags determining whether local echo was emulated by the kernel's terminal driver, whether modem flow control was enabled, the lengths of various output delays, mapping for the carriage return character, and the three input modes.[24]
The three input modes were:
line mode (also called "cooked" mode)
Main article: cooked mode
In line mode the line discipline performs all line editing functions and recognizes the "interrupt" and "quit" control characters and transforms them into signals sent to processes. Applications programs reading from the terminal receive entire lines, after line editing has been completed by the user pressing return.[21][25]
cbreak mode
Main article: cbreak mode
cbreak mode is one of two character-at-a-time modes. (Stephen R. Bourne jokingly referred to it (Bourne 1983, p. 288) as a "half-cooked" and therefore "rare" mode.) The line discipline performs no line editing, and the control sequences for line editing functions are treated as normal character input. Applications programs reading from the terminal receive characters immediately, as soon as they are available in the input queue to be read. However, the "interrupt" and "quit" control characters, as well as modem flow control characters, are still handled specially and stripped from the input stream.[26][27]
raw mode
raw mode is the other of the two character-at-a-time modes. The line discipline performs no line editing, and the control sequences for both line editing functions and the various special characters ("interrupt", "quit", and flow control) are treated as normal character input. Applications programs reading from the terminal receive characters immediately, and receive the entire character stream unaltered, just as it came from the terminal device itself.[28][26][27]
The programmatic interface for querying and modifying all of these modes and control characters was the ioctl() system call. (This replaced the stty() and gtty() system calls of Sixth Edition Unix.)[29][30] Although the "erase" and "kill" characters were modifiable from their defaults of # and @, for many years they were the pre-set defaults in the terminal device drivers, and on many Unix systems, which only altered terminal device settings as part of the login process, in system login scripts that ran after the user had entered username and password, any mistakes at the login and password prompts had to be corrected using the historical editing key characters inherited from teletypewriter terminals.[23]
The terms raw and cooked only apply to terminal drivers. "Cooked" is called canonical and "raw" is called non-canonical mode.
The terminal driver is, by default a line-based system: characters are buffered internally until a carriage return (Enter or Return) before it is passed to the program - this is called "cooked". This allows certain characters to be processed (see stty(1)), such as Cntl-D, Cntl-S, Ctrl-U Backspace); essentially rudimentary line-editing. The terminal driver "cooks" the characters before serving them up
The terminal can be placed into "raw" mode where the characters are not processed by the terminal driver, but are sent straight through (it can be set that INTR and QUIT characters are still processed). This allows programs like emacs and vi to use the entire screen more easily.
You can read more about this in the "Canonical mode" section of the termios(3) manpage.
stty---change and print terminal line settings
-a, print all current settings in human-readable form.
TTY
终端设备的简称
tty - controlling terminal
DESCRIPTION top
The file /dev/tty is a character file with major number 5 and minor number 0, usually of mode 0666 and owner.group root.tty. It is a synonym for the controlling terminal of a process, if any. In addition to the ioctl(2) requests supported by the device that tty refers to, the ioctl(2) request TIOCNOTTY is supported. TIOCNOTTY Detach the calling process from its controlling terminal. If the process is the session leader, then SIGHUP and SIGCONT signals are sent to the foreground process group and all processes in the current session lose their controlling tty. This ioctl(2) call works only on file descriptors connected to /dev/tty. It is used by daemon processes when they are invoked by a user at a terminal. The process attempts to open /dev/tty. If the open succeeds, it detaches itself from the terminal by using TIOCNOTTY, while if the open failszi, it is obviously not attached to a terminal and does not need to detach itself.
Booting
In general parlance, bootstrapping usually refers to a self-starting process that is supposed to proceed without external input. Incomputer technology the term (usually shortened to booting) usually refers to the process of loading the basic software into the memory of a computer after power-on or general reset, especially the operating system which will then take care of loading other software as needed.
Booting is the process of starting a computer, specifically with regard to starting its software. The process involves a chain of stages, in which at each stage a smaller simpler program loads and then executes the larger more complicated program of the next stage. It is in this sense that the computer "pulls itself up by its bootstraps", i.e. it improves itself by its own efforts. Booting is a chain of events that starts with execution of hardware-based procedures and may then hand-off to firmware and software which is loaded into main memory. Booting often involves processes such as performing self-tests, loading configuration settings, loading a BIOS(a type offirmware used to perform hardware initialization during the bootingprocess (power-on startup) on IBM PC compatible computers, and to provide runtime services for operating systems and programs.),resident monitors, a hypervisor, an operating system, or utility software.
转载于:https://blog.51cto.com/11259454/1764347
905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
