10 Days of learning the fourth day of the Linux kernel---How to handle input and output operations

10 Days of learning the fourth day of the Linux kernel---How to handle input/output operations

Really is sad and happy, originally this winter vacation morning 8 to practice cars, two hours later to accompany the Linux kernel lab, but today the coach said there is no place to test, good entanglements, but think can sleep late, haha, since the junior winter vacation has not slept lazy sleep it, Now also have more time to share their own learning of the Linux kernel feeling, a few days ago felt that they are also some do not understand, I believe you see is also very vague, I will sign out of their own do not understand, I hope the great God advice, but also hope that we have a lot of guidance, common to conquer the Linux kernel, Today will talk about how the processor interacts with other devices, and how the kernel responds and controls these interactions, today the content is not much but the key, write bad hope everybody criticize, pure hand dozen.

How does the Linux kernel combine hardware and software? Here we will explore the relationship between the kernel and the surrounding hardware, mainly the file IO and hardware devices, to explain this problem. The communication between the processor and the surrounding equipment depends on a series of circuit wires, the bus is a similar function of the wire, equipment and processor communication is mainly through the address bus, data bus, control bus to achieve, here in the study of the principle of single-chip microcomputer also mentioned, here on the basic structure of the system is not much said, feel updated fast, Not good to explain, there is nothing to summarize, we look at the relevant books on the line. Knowing that the device can be treated as a file in the file system, its details can be hidden in the kernel, and the application programmer is transparent, when the process to the device file application of a system call, as long as the system call to a certain device function to convert it is sufficient, wherein the device driver defines these functions, Next look at these device types. The relationship between the application layer, the filesystem layer, the universal block device layer, and the device driver is posted here for your information. Read-write block devices are as follows:

First introduce the block device, device driver registers for itself when the driver initializes, adds this driver to the kernel driver table, and maps the device number to the data structure block_device_operations, the data structure Block_device_ The operations contains functions that start and stop to the set block device in the system (on Include/linux/fs.h.

structblock_operations{int(*open) (structInode *,structFile *); int(*release) (structInode *,structfile*); Open () and release () are synchronizedint(*IOCTL) (structNode *,structFile *,unsigned, unsignedLong); int(*media_changed) (structGendisk *); int(*revalidate_disk) (structGendisk *); structModule *owner;};

From the processor's point of view, locating the head on the appropriate CIDAO4 and transferring the disk to the appropriate block takes a considerable amount of time, forcing the kernel to implement the system request queue. In Linux2.6, each block device has its own request queue to manage IO port requests to the device, and the process can update the request queue of the device only after the request queue lock has been obtained, so let's take a look at the Request_queue structure ( the code is knocked out by itself, Then analysis, analysis of the poor please the great God to criticize the correction. This code can be viewed in include/linux/blkdev.h.

structrequest_queue{structList_head Queue_head; Pointer to the top of the request queuestructRequest *Last_merge;　　　　　　The last request added to the request queue elevator_t elevator;  This does not understand, ask the big God to teach structRequest_list RQ; Consists of two wait_queue, respectively, for block device read request queue and write request queue ... Request_fn_proc*REQUEST_FN; MERGE_REQUEST_FN*BACK_MERGE_FN; MERGE_REQUEST_FN*FRONT_MERGE_FN; MERGE_REQUESTS_FN*MERGE_REQUESTS_FN; MAKE_REQUEST_FN*MAKE_REQUEST_FN; PREP_RQ_FN*PREP_RQ_FN; UNPLUG_FN*UNPLUG_FN; MERGE_BVEC_FN*MERGE_BVEC_FN; ACTIVITY_FN*ACTIVITY_FN; Define scheduler-related functions to control how requests for block devices are managed ...structtime_list Unplug_timer; intUnplug_thresh; unsignedLongUnplug_delay; structwork_struct unplug_work; structBacking_dev_info Backing_dev_info; Io scheduling function for removing devices ...void*Queuedata; void*Activity_data; These are the queues that are related to device and device driver management ... unsignedLongBOUNCE_PFN; intBOUNCE_GFP; Refers to the kernel to copy the IO request of the high-end memory cache flush to the low-end memory buffer unsignedLongqueue_flags;//variable Queue_flags stores one or more queue flags, see the table below.

Flag Name	Function
Queue_flag_cluster	To synthesize a few segments into a
queue_flag_queued	Using the Universal flag queue
queue_flag_stopped	Queue is stopped
Queue_flag_readfull	The read queue is full.
Queue_flag_writefull	The write queue is full.
Queue_flag_dead	Queue is revoked
Queue_flag_reenter	Avoid re-entry
Queue_flag_plugged	Insert Queue

spinlock_t *Queue_lock;structKobject kobj;unsignedLongnr_requests; unsignedintnr_congestion_on;unsignedintnr_congestion_off;unsigned Shortmax_sectors;unsigned Shortmax_phys_segments;unsigned Shortmax_hw_segments;unsigned Shorthardsect_size;unsignedintmax_segment_size;unsignedLongseg_boundary_mask;unsignedLongdma_alignment;structBlk_queue_tag *queue_tags;atomic_t refcnt;unsignedintin_flight;unsignedintsg_timeout;unsignedintsg_reserved_size; The preceding variables define the resources that can be managed in the request queue

};

The Linux kernel initializes the request queue for the block device by calling the following function in the device's _init function, which, in these functions, can be seen in the request for internal details and related help tutorials, In the current Linux2.6 kernel, each block device controls its own lock and passes the spin lock as a second parameter, where the first parameter is the request function provided by the block device driver, and the following code is seen in DRIVERS/BLOCK/11_RW_BLK.C.

request_queue_t *blk_init_queue (Request_fn_proc *rfn,spinlock_t *Lock) {request_queue_t*Q; Static intprinted; Q=Blk_alloc_queue (Gfp_kernel); Allocates a space queue from the kernel's memory, with a content of 0if(!q)returnNULL; if(Blk_init_free_list (q))//initialization Request ChecklistGotoOut_init; always afraid of Goto, understand but not useif(!printed) {Printed=1; PRINTK ("Using%s io scheduler\n",chosen_elevator->elevator_name); }    if(Elevator_init (Q,chosen_elevator))//This is an initialized functionGotoOut_elv; Q-&GT;REQUEST_FN =RFN; Q-&GT;BACK_MERGE_FN =11_BACK_MERGE_FN; Q-&GT;FRONT_MERGE_FN =11_FRONT_MERGE_FN; Q-&GT;MERGE_REQUESTS_FN =11_MERGE_REQUESTS_FN; Q-&GT;PREP_RQ_FN =NULL; Q-&GT;UNPLUG_FN =Generic_unplug_device; Q->queue_flags = (1<<queue_flag_cluster); Q->queue_lock =Lock; The above assignment is a function associated with the elevator dispatcher associated with the queue blk_queue_segment_boundary (q,0xFFFFFFFF);　　Check whether the minimum size is met blk_queue_make_request (q,__make_request)//Set driver to remove Blk_queue_max_segment_size (q,max_segment_size) from the queue;　　Initializes the upper bound of the merge segment Blk_queue_max_hw_segments (q,max_hw_segments);　　Initializes the maximum number of segments that a physical device can handle blk_queue_max_phys_segments (q,max_phys_segments); Initializes the maximum number of physical segments per requestreturnQ0;    Returns the already initialized queue Out_elv:blk_cleanup_queue (q);    Out_init:kmem_cache_free (REQUESTQ_CACHEP,Q); returnNULL; A routine that clears memory in an error event}

　　

Code is too difficult, I know is only fur, those need to have a good experience, if there is a supplementary hope that the big God can be more correct my shortcomings, now look at the device operation, the basic universal block device has OPEN,CLOSE,IOCTL and request function, requests queue can not be directly accessed, However, it can be accessed through a set of helper routines, as follows:

struct request *elv_next_request (request_queue_t *q)

This help function returns a pointer to the next request structure that the driver can use to view the element to gather all the information to determine its size direction and any other custom actions associated with the request, and then report this information to the kernel via End_request ():

void end_request (struct request *req,int  uptodate)//pass Elev_next_request in Request queue () The obtained parameter {    if(!end_that_request_first (req,uptpdate,req->hrad_cur_sectors))//transmit the appropriate number    of sectors　　{        add_disk_randomness (req-rq_disk);　　join the system entropy pool, say do not understand, ask the great God advice ,        blkdev_dequeue_request (req);　　Delete request Structure        end_that_request_last (req); Collect statistics and release available data Structures}    }

Here to introduce a variety of other devices, unlike block devices, character devices are used to transmit data streams, all serial devices are character devices, similar to character devices, network equipment data on the physical layer of transmission, and clock equipment is based on hardware pulse-beating device, in fact, is the clock-related, and the terminal equipment, Here is a little mention. Because these are related to the input and output, as long as you have an impression on the line.

　　

　　Summary

End of the analysis of the Code journey, summary of today's main content, the main share today is how the Linux kernel handles the input and output operations, specifically discusses how Linux represents the block device and its interface, also introduced the Linux scheduler and focused on the request queue, the above-mentioned knock code, I also have a lot of do not understand, only their own slowly to understand, hope that the big God after the road can be a little reminder, hey, this winter vacation no matter, has been and the core to accompany it, these write bad, and then continue to work hard, fighting~

All rights reserved, reprint please specify reprint address: http://www.cnblogs.com/lihuidashen/p/4244330.html

10 Days of learning the fourth day of the Linux kernel---How to handle input and output operations