aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--drivers/block/pktcdvd.c48
1 files changed, 30 insertions, 18 deletions
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 58d01c820799..aacf5cfccada 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -5,29 +5,41 @@
5 * May be copied or modified under the terms of the GNU General Public 5 * May be copied or modified under the terms of the GNU General Public
6 * License. See linux/COPYING for more information. 6 * License. See linux/COPYING for more information.
7 * 7 *
8 * Packet writing layer for ATAPI and SCSI CD-R, CD-RW, DVD-R, and 8 * Packet writing layer for ATAPI and SCSI CD-RW, DVD+RW, DVD-RW and
9 * DVD-RW devices (aka an exercise in block layer masturbation) 9 * DVD-RAM devices.
10 * 10 *
11 * Theory of operation:
11 * 12 *
12 * TODO: (circa order of when I will fix it) 13 * At the lowest level, there is the standard driver for the CD/DVD device,
13 * - Only able to write on CD-RW media right now. 14 * typically ide-cd.c or sr.c. This driver can handle read and write requests,
14 * - check host application code on media and set it in write page 15 * but it doesn't know anything about the special restrictions that apply to
15 * - interface for UDF <-> packet to negotiate a new location when a write 16 * packet writing. One restriction is that write requests must be aligned to
16 * fails. 17 * packet boundaries on the physical media, and the size of a write request
17 * - handle OPC, especially for -RW media 18 * must be equal to the packet size. Another restriction is that a
19 * GPCMD_FLUSH_CACHE command has to be issued to the drive before a read
20 * command, if the previous command was a write.
18 * 21 *
19 * Theory of operation: 22 * The purpose of the packet writing driver is to hide these restrictions from
23 * higher layers, such as file systems, and present a block device that can be
24 * randomly read and written using 2kB-sized blocks.
25 *
26 * The lowest layer in the packet writing driver is the packet I/O scheduler.
27 * Its data is defined by the struct packet_iosched and includes two bio
28 * queues with pending read and write requests. These queues are processed
29 * by the pkt_iosched_process_queue() function. The write requests in this
30 * queue are already properly aligned and sized. This layer is responsible for
31 * issuing the flush cache commands and scheduling the I/O in a good order.
20 * 32 *
21 * We use a custom make_request_fn function that forwards reads directly to 33 * The next layer transforms unaligned write requests to aligned writes. This
22 * the underlying CD device. Write requests are either attached directly to 34 * transformation requires reading missing pieces of data from the underlying
23 * a live packet_data object, or simply stored sequentially in a list for 35 * block device, assembling the pieces to full packets and queuing them to the
24 * later processing by the kcdrwd kernel thread. This driver doesn't use 36 * packet I/O scheduler.
25 * any elevator functionally as defined by the elevator_s struct, but the
26 * underlying CD device uses a standard elevator.
27 * 37 *
28 * This strategy makes it possible to do very late merging of IO requests. 38 * At the top layer there is a custom make_request_fn function that forwards
29 * A new bio sent to pkt_make_request can be merged with a live packet_data 39 * read requests directly to the iosched queue and puts write requests in the
30 * object even if the object is in the data gathering state. 40 * unaligned write queue. A kernel thread performs the necessary read
41 * gathering to convert the unaligned writes to aligned writes and then feeds
42 * them to the packet I/O scheduler.
31 * 43 *
32 *************************************************************************/ 44 *************************************************************************/
33 45