Linux Kernel Architecture

Chapter 6: Device Drivers

Thedoloop is now executed a second time. Before the second — iterative! — call to__genericmake
request, the data structure looks as in Figure 6-17(c), and the secondbioinstance is processed. If no
more BIOs are submitted recursively, the job is done afterward.

The method also works if__generic_make_requestcallsgeneric_make_requestmore than once. Imag-
ine that three additional BIOs are submitted. The resulting data structure is depicted in Figure 6-17(d). If
no more BIOs are submitted afterward, the loop processes the existing BIO instances one after another
and then returns.

After having resolved the difficulties with recursivegeneric_make_requestcalls, we can go on to exam-
ine the defaultmake_request_fnimplementation__make_request.Figure6-18showsthecodeflow
diagram.^13

Read information from bio

elv_queue_empty?

Implement elevator guideline

Unplug queue (if necessary) and quit function

Setup request instance

Queue unplugged and unplug threshold reached?

_ _make_request

blk_plug_device

elv_merge

get_request_wait

add_request _ _elv_add_request_pos

_ _generic_unplug_device

Figure 6-18: Code flow diagram for__make_request.

Once the information needed to create the request has been read from the passedbioinstance, the kernel
invokeselv_queue_emptyto check whether the elevator queue is currently empty. If so, work is made
easier as there is no need to merge the request with existing requests (because none is present).

If there are pending requests in the queue,elv_mergeis called to invoke theelevator_merge_fnfunction
of theelevatorelement associated with the request queue (Section 6.5.8 deals with the implementation
of I/O schedulers). At this point, we are interested only in the result of the function. It returns a pointer
to the request list position at which the new request is to be inserted. The I/O scheduler also specifies
whether and how the request is to be coalesced with existing requests.

(^13) As a slight simplification, I omit bounce buffer handling. Older hardware might only be able to transfer data into some specific
region in memory. In this case, the kernel initiates the transfer to go into this region and copies the result to some more apt place
after the transfer is finished.