forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (95 commits) ide-tape: remove idetape_config_t typedef ide-tape: remove mtio.h related comments ide-tape: make function name more accurate ide-tape: remove unused sense packet commands. ide-tape: use generic byteorder macros ide-tape: remove EXPERIMENTAL driver status ide-tape: use generic scsi commands ide-tape: remove struct idetape_block_size_page_t ide-tape: remove structs os_partition_t, os_dat_entry_t, os_dat_t ide-tape: remove struct idetape_parameter_block_descriptor_t ide-tape: remove struct idetape_medium_partition_page_t ide-tape: remove struct idetape_data_compression_page_t ide-tape: remove struct idetape_inquiry_result_t ide-tape: remove struct idetape_capabilities_page_t ide-tape: remove IDETAPE_DEBUG_BUGS ide-tape: remove IDETAPE_DEBUG_INFO ide-tape: dump gcw fields on error in idetape_identify_device() ide-tape: remove struct idetape_mode_parameter_header_t ide-tape: remove struct idetape_request_sense_result_t ide-tape: remove dead code ...
- Loading branch information
Showing
77 changed files
with
1,989 additions
and
2,849 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,146 @@ | ||
| /* | ||
| * IDE ATAPI streaming tape driver. | ||
| * | ||
| * This driver is a part of the Linux ide driver. | ||
| * | ||
| * The driver, in co-operation with ide.c, basically traverses the | ||
| * request-list for the block device interface. The character device | ||
| * interface, on the other hand, creates new requests, adds them | ||
| * to the request-list of the block device, and waits for their completion. | ||
| * | ||
| * Pipelined operation mode is now supported on both reads and writes. | ||
| * | ||
| * The block device major and minor numbers are determined from the | ||
| * tape's relative position in the ide interfaces, as explained in ide.c. | ||
| * | ||
| * The character device interface consists of the following devices: | ||
| * | ||
| * ht0 major 37, minor 0 first IDE tape, rewind on close. | ||
| * ht1 major 37, minor 1 second IDE tape, rewind on close. | ||
| * ... | ||
| * nht0 major 37, minor 128 first IDE tape, no rewind on close. | ||
| * nht1 major 37, minor 129 second IDE tape, no rewind on close. | ||
| * ... | ||
| * | ||
| * The general magnetic tape commands compatible interface, as defined by | ||
| * include/linux/mtio.h, is accessible through the character device. | ||
| * | ||
| * General ide driver configuration options, such as the interrupt-unmask | ||
| * flag, can be configured by issuing an ioctl to the block device interface, | ||
| * as any other ide device. | ||
| * | ||
| * Our own ide-tape ioctl's can be issued to either the block device or | ||
| * the character device interface. | ||
| * | ||
| * Maximal throughput with minimal bus load will usually be achieved in the | ||
| * following scenario: | ||
| * | ||
| * 1. ide-tape is operating in the pipelined operation mode. | ||
| * 2. No buffering is performed by the user backup program. | ||
| * | ||
| * Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive. | ||
| * | ||
| * Here are some words from the first releases of hd.c, which are quoted | ||
| * in ide.c and apply here as well: | ||
| * | ||
| * | Special care is recommended. Have Fun! | ||
| * | ||
| * | ||
| * An overview of the pipelined operation mode. | ||
| * | ||
| * In the pipelined write mode, we will usually just add requests to our | ||
| * pipeline and return immediately, before we even start to service them. The | ||
| * user program will then have enough time to prepare the next request while | ||
| * we are still busy servicing previous requests. In the pipelined read mode, | ||
| * the situation is similar - we add read-ahead requests into the pipeline, | ||
| * before the user even requested them. | ||
| * | ||
| * The pipeline can be viewed as a "safety net" which will be activated when | ||
| * the system load is high and prevents the user backup program from keeping up | ||
| * with the current tape speed. At this point, the pipeline will get | ||
| * shorter and shorter but the tape will still be streaming at the same speed. | ||
| * Assuming we have enough pipeline stages, the system load will hopefully | ||
| * decrease before the pipeline is completely empty, and the backup program | ||
| * will be able to "catch up" and refill the pipeline again. | ||
| * | ||
| * When using the pipelined mode, it would be best to disable any type of | ||
| * buffering done by the user program, as ide-tape already provides all the | ||
| * benefits in the kernel, where it can be done in a more efficient way. | ||
| * As we will usually not block the user program on a request, the most | ||
| * efficient user code will then be a simple read-write-read-... cycle. | ||
| * Any additional logic will usually just slow down the backup process. | ||
| * | ||
| * Using the pipelined mode, I get a constant over 400 KBps throughput, | ||
| * which seems to be the maximum throughput supported by my tape. | ||
| * | ||
| * However, there are some downfalls: | ||
| * | ||
| * 1. We use memory (for data buffers) in proportional to the number | ||
| * of pipeline stages (each stage is about 26 KB with my tape). | ||
| * 2. In the pipelined write mode, we cheat and postpone error codes | ||
| * to the user task. In read mode, the actual tape position | ||
| * will be a bit further than the last requested block. | ||
| * | ||
| * Concerning (1): | ||
| * | ||
| * 1. We allocate stages dynamically only when we need them. When | ||
| * we don't need them, we don't consume additional memory. In | ||
| * case we can't allocate stages, we just manage without them | ||
| * (at the expense of decreased throughput) so when Linux is | ||
| * tight in memory, we will not pose additional difficulties. | ||
| * | ||
| * 2. The maximum number of stages (which is, in fact, the maximum | ||
| * amount of memory) which we allocate is limited by the compile | ||
| * time parameter IDETAPE_MAX_PIPELINE_STAGES. | ||
| * | ||
| * 3. The maximum number of stages is a controlled parameter - We | ||
| * don't start from the user defined maximum number of stages | ||
| * but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we | ||
| * will not even allocate this amount of stages if the user | ||
| * program can't handle the speed). We then implement a feedback | ||
| * loop which checks if the pipeline is empty, and if it is, we | ||
| * increase the maximum number of stages as necessary until we | ||
| * reach the optimum value which just manages to keep the tape | ||
| * busy with minimum allocated memory or until we reach | ||
| * IDETAPE_MAX_PIPELINE_STAGES. | ||
| * | ||
| * Concerning (2): | ||
| * | ||
| * In pipelined write mode, ide-tape can not return accurate error codes | ||
| * to the user program since we usually just add the request to the | ||
| * pipeline without waiting for it to be serviced. In case an error | ||
| * occurs, I will report it on the next user request. | ||
| * | ||
| * In the pipelined read mode, subsequent read requests or forward | ||
| * filemark spacing will perform correctly, as we preserve all blocks | ||
| * and filemarks which we encountered during our excess read-ahead. | ||
| * | ||
| * For accurate tape positioning and error reporting, disabling | ||
| * pipelined mode might be the best option. | ||
| * | ||
| * You can enable/disable/tune the pipelined operation mode by adjusting | ||
| * the compile time parameters below. | ||
| * | ||
| * | ||
| * Possible improvements. | ||
| * | ||
| * 1. Support for the ATAPI overlap protocol. | ||
| * | ||
| * In order to maximize bus throughput, we currently use the DSC | ||
| * overlap method which enables ide.c to service requests from the | ||
| * other device while the tape is busy executing a command. The | ||
| * DSC overlap method involves polling the tape's status register | ||
| * for the DSC bit, and servicing the other device while the tape | ||
| * isn't ready. | ||
| * | ||
| * In the current QIC development standard (December 1995), | ||
| * it is recommended that new tape drives will *in addition* | ||
| * implement the ATAPI overlap protocol, which is used for the | ||
| * same purpose - efficient use of the IDE bus, but is interrupt | ||
| * driven and thus has much less CPU overhead. | ||
| * | ||
| * ATAPI overlap is likely to be supported in most new ATAPI | ||
| * devices, including new ATAPI cdroms, and thus provides us | ||
| * a method by which we can achieve higher throughput when | ||
| * sharing a (fast) ATA-2 disk with any (slow) new ATAPI device. | ||
| */ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.