Commit a676f8d0 authored by Peter Osterlund's avatar Peter Osterlund Committed by Linus Torvalds

[PATCH] pktcdvd: documentation update

Update the "theory of operation" description.
Signed-off-by: default avatarPeter Osterlund <petero2@telia.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
parent d0272e78
...@@ -5,29 +5,41 @@ ...@@ -5,29 +5,41 @@
* May be copied or modified under the terms of the GNU General Public * May be copied or modified under the terms of the GNU General Public
* License. See linux/COPYING for more information. * License. See linux/COPYING for more information.
* *
* Packet writing layer for ATAPI and SCSI CD-R, CD-RW, DVD-R, and * Packet writing layer for ATAPI and SCSI CD-RW, DVD+RW, DVD-RW and
* DVD-RW devices (aka an exercise in block layer masturbation) * DVD-RAM devices.
* *
* Theory of operation:
* *
* TODO: (circa order of when I will fix it) * At the lowest level, there is the standard driver for the CD/DVD device,
* - Only able to write on CD-RW media right now. * typically ide-cd.c or sr.c. This driver can handle read and write requests,
* - check host application code on media and set it in write page * but it doesn't know anything about the special restrictions that apply to
* - interface for UDF <-> packet to negotiate a new location when a write * packet writing. One restriction is that write requests must be aligned to
* fails. * packet boundaries on the physical media, and the size of a write request
* - handle OPC, especially for -RW media * must be equal to the packet size. Another restriction is that a
* GPCMD_FLUSH_CACHE command has to be issued to the drive before a read
* command, if the previous command was a write.
* *
* Theory of operation: * The purpose of the packet writing driver is to hide these restrictions from
* higher layers, such as file systems, and present a block device that can be
* randomly read and written using 2kB-sized blocks.
*
* The lowest layer in the packet writing driver is the packet I/O scheduler.
* Its data is defined by the struct packet_iosched and includes two bio
* queues with pending read and write requests. These queues are processed
* by the pkt_iosched_process_queue() function. The write requests in this
* queue are already properly aligned and sized. This layer is responsible for
* issuing the flush cache commands and scheduling the I/O in a good order.
* *
* We use a custom make_request_fn function that forwards reads directly to * The next layer transforms unaligned write requests to aligned writes. This
* the underlying CD device. Write requests are either attached directly to * transformation requires reading missing pieces of data from the underlying
* a live packet_data object, or simply stored sequentially in a list for * block device, assembling the pieces to full packets and queuing them to the
* later processing by the kcdrwd kernel thread. This driver doesn't use * packet I/O scheduler.
* any elevator functionally as defined by the elevator_s struct, but the
* underlying CD device uses a standard elevator.
* *
* This strategy makes it possible to do very late merging of IO requests. * At the top layer there is a custom make_request_fn function that forwards
* A new bio sent to pkt_make_request can be merged with a live packet_data * read requests directly to the iosched queue and puts write requests in the
* object even if the object is in the data gathering state. * unaligned write queue. A kernel thread performs the necessary read
* gathering to convert the unaligned writes to aligned writes and then feeds
* them to the packet I/O scheduler.
* *
*************************************************************************/ *************************************************************************/
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment