* [PATCH 0/32] ide-tape redux v1
@ 2008-01-27 8:41 Borislav Petkov
2008-01-27 8:41 ` [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002 Borislav Petkov
` (5 more replies)
0 siblings, 6 replies; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hi Bart,
after a lot of hammering ide-tape got pimped pretty considerably (ca. 600 lines
shorter and slicker :)). I'm sure there's more to be done like, e.g. replacing
the BKL in idetape_write_release() with finer-grained locking etc, probably also
some pipeline improvements, removal of OnStream support, etc. but that'll come
later.
Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++
drivers/ide/Kconfig | 3 +-
drivers/ide/ide-tape.c | 4146 +++++++++---------------
3 files changed, 1991 insertions(+), 2563 deletions(-)
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
@ 2008-01-27 8:41 ` Borislav Petkov
2008-01-27 15:18 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 2/32] ide-tape: remove dead code Borislav Petkov
` (4 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
Also, cleanup whitespace and update comments.
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++++++++++++++++++++++
drivers/ide/ide-tape.c | 414 +-----------------------
2 files changed, 409 insertions(+), 410 deletions(-)
diff --git a/Documentation/ide/ChangeLog.ide-tape.1995-2002 b/Documentation/ide/ChangeLog.ide-tape.1995-2002
new file mode 100644
index 0000000..e406762
--- /dev/null
+++ b/Documentation/ide/ChangeLog.ide-tape.1995-2002
@@ -0,0 +1,405 @@
+/*
+ * IDE ATAPI streaming tape driver.
+ *
+ * This driver is a part of the Linux ide driver and works in co-operation
+ * with drivers/block/ide.c.
+ *
+ * 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.
+ *
+ * Ver 0.1 Nov 1 95 Pre-working code :-)
+ * Ver 0.2 Nov 23 95 A short backup (few megabytes) and restore procedure
+ * was successful ! (Using tar cvf ... on the block
+ * device interface).
+ * A longer backup resulted in major swapping, bad
+ * overall Linux performance and eventually failed as
+ * we received non serial read-ahead requests from the
+ * buffer cache.
+ * Ver 0.3 Nov 28 95 Long backups are now possible, thanks to the
+ * character device interface. Linux's responsiveness
+ * and performance doesn't seem to be much affected
+ * from the background backup procedure.
+ * Some general mtio.h magnetic tape operations are
+ * now supported by our character device. As a result,
+ * popular tape utilities are starting to work with
+ * ide tapes :-)
+ * The following configurations were tested:
+ * 1. An IDE ATAPI TAPE shares the same interface
+ * and irq with an IDE ATAPI CDROM.
+ * 2. An IDE ATAPI TAPE shares the same interface
+ * and irq with a normal IDE disk.
+ * Both configurations seemed to work just fine !
+ * However, to be on the safe side, it is meanwhile
+ * recommended to give the IDE TAPE its own interface
+ * and irq.
+ * The one thing which needs to be done here is to
+ * add a "request postpone" feature to ide.c,
+ * so that we won't have to wait for the tape to finish
+ * performing a long media access (DSC) request (such
+ * as a rewind) before we can access the other device
+ * on the same interface. This effect doesn't disturb
+ * normal operation most of the time because read/write
+ * requests are relatively fast, and once we are
+ * performing one tape r/w request, a lot of requests
+ * from the other device can be queued and ide.c will
+ * service all of them after this single tape request.
+ * Ver 1.0 Dec 11 95 Integrated into Linux 1.3.46 development tree.
+ * On each read / write request, we now ask the drive
+ * if we can transfer a constant number of bytes
+ * (a parameter of the drive) only to its buffers,
+ * without causing actual media access. If we can't,
+ * we just wait until we can by polling the DSC bit.
+ * This ensures that while we are not transferring
+ * more bytes than the constant referred to above, the
+ * interrupt latency will not become too high and
+ * we won't cause an interrupt timeout, as happened
+ * occasionally in the previous version.
+ * While polling for DSC, the current request is
+ * postponed and ide.c is free to handle requests from
+ * the other device. This is handled transparently to
+ * ide.c. The hwgroup locking method which was used
+ * in the previous version was removed.
+ * Use of new general features which are provided by
+ * ide.c for use with atapi devices.
+ * (Programming done by Mark Lord)
+ * Few potential bug fixes (Again, suggested by Mark)
+ * Single character device data transfers are now
+ * not limited in size, as they were before.
+ * We are asking the tape about its recommended
+ * transfer unit and send a larger data transfer
+ * as several transfers of the above size.
+ * For best results, use an integral number of this
+ * basic unit (which is shown during driver
+ * initialization). I will soon add an ioctl to get
+ * this important parameter.
+ * Our data transfer buffer is allocated on startup,
+ * rather than before each data transfer. This should
+ * ensure that we will indeed have a data buffer.
+ * Ver 1.1 Dec 14 95 Fixed random problems which occurred when the tape
+ * shared an interface with another device.
+ * (poll_for_dsc was a complete mess).
+ * Removed some old (non-active) code which had
+ * to do with supporting buffer cache originated
+ * requests.
+ * The block device interface can now be opened, so
+ * that general ide driver features like the unmask
+ * interrupts flag can be selected with an ioctl.
+ * This is the only use of the block device interface.
+ * New fast pipelined operation mode (currently only on
+ * writes). When using the pipelined mode, the
+ * throughput can potentially reach the maximum
+ * tape supported throughput, regardless of the
+ * user backup program. On my tape drive, it sometimes
+ * boosted performance by a factor of 2. Pipelined
+ * mode is enabled by default, but since it has a few
+ * downfalls as well, you may want to disable it.
+ * A short explanation of the pipelined operation mode
+ * is available below.
+ * Ver 1.2 Jan 1 96 Eliminated pipelined mode race condition.
+ * Added pipeline read mode. As a result, restores
+ * are now as fast as backups.
+ * Optimized shared interface behavior. The new behavior
+ * typically results in better IDE bus efficiency and
+ * higher tape throughput.
+ * Pre-calculation of the expected read/write request
+ * service time, based on the tape's parameters. In
+ * the pipelined operation mode, this allows us to
+ * adjust our polling frequency to a much lower value,
+ * and thus to dramatically reduce our load on Linux,
+ * without any decrease in performance.
+ * Implemented additional mtio.h operations.
+ * The recommended user block size is returned by
+ * the MTIOCGET ioctl.
+ * Additional minor changes.
+ * Ver 1.3 Feb 9 96 Fixed pipelined read mode bug which prevented the
+ * use of some block sizes during a restore procedure.
+ * The character device interface will now present a
+ * continuous view of the media - any mix of block sizes
+ * during a backup/restore procedure is supported. The
+ * driver will buffer the requests internally and
+ * convert them to the tape's recommended transfer
+ * unit, making performance almost independent of the
+ * chosen user block size.
+ * Some improvements in error recovery.
+ * By cooperating with ide-dma.c, bus mastering DMA can
+ * now sometimes be used with IDE tape drives as well.
+ * Bus mastering DMA has the potential to dramatically
+ * reduce the CPU's overhead when accessing the device,
+ * and can be enabled by using hdparm -d1 on the tape's
+ * block device interface. For more info, read the
+ * comments in ide-dma.c.
+ * Ver 1.4 Mar 13 96 Fixed serialize support.
+ * Ver 1.5 Apr 12 96 Fixed shared interface operation, broken in 1.3.85.
+ * Fixed pipelined read mode inefficiency.
+ * Fixed nasty null dereferencing bug.
+ * Ver 1.6 Aug 16 96 Fixed FPU usage in the driver.
+ * Fixed end of media bug.
+ * Ver 1.7 Sep 10 96 Minor changes for the CONNER CTT8000-A model.
+ * Ver 1.8 Sep 26 96 Attempt to find a better balance between good
+ * interactive response and high system throughput.
+ * Ver 1.9 Nov 5 96 Automatically cross encountered filemarks rather
+ * than requiring an explicit FSF command.
+ * Abort pending requests at end of media.
+ * MTTELL was sometimes returning incorrect results.
+ * Return the real block size in the MTIOCGET ioctl.
+ * Some error recovery bug fixes.
+ * Ver 1.10 Nov 5 96 Major reorganization.
+ * Reduced CPU overhead a bit by eliminating internal
+ * bounce buffers.
+ * Added module support.
+ * Added multiple tape drives support.
+ * Added partition support.
+ * Rewrote DSC handling.
+ * Some portability fixes.
+ * Removed ide-tape.h.
+ * Additional minor changes.
+ * Ver 1.11 Dec 2 96 Bug fix in previous DSC timeout handling.
+ * Use ide_stall_queue() for DSC overlap.
+ * Use the maximum speed rather than the current speed
+ * to compute the request service time.
+ * Ver 1.12 Dec 7 97 Fix random memory overwriting and/or last block data
+ * corruption, which could occur if the total number
+ * of bytes written to the tape was not an integral
+ * number of tape blocks.
+ * Add support for INTERRUPT DRQ devices.
+ * Ver 1.13 Jan 2 98 Add "speed == 0" work-around for HP COLORADO 5GB
+ * Ver 1.14 Dec 30 98 Partial fixes for the Sony/AIWA tape drives.
+ * Replace cli()/sti() with hwgroup spinlocks.
+ * Ver 1.15 Mar 25 99 Fix SMP race condition by replacing hwgroup
+ * spinlock with private per-tape spinlock.
+ * Ver 1.16 Sep 1 99 Add OnStream tape support.
+ * Abort read pipeline on EOD.
+ * Wait for the tape to become ready in case it returns
+ * "in the process of becoming ready" on open().
+ * Fix zero padding of the last written block in
+ * case the tape block size is larger than PAGE_SIZE.
+ * Decrease the default disconnection time to tn.
+ * Ver 1.16e Oct 3 99 Minor fixes.
+ * Ver 1.16e1 Oct 13 99 Patches by Arnold Niessen,
+ * niessen@iae.nl / arnold.niessen@philips.com
+ * GO-1) Undefined code in idetape_read_position
+ * according to Gadi's email
+ * AJN-1) Minor fix asc == 11 should be asc == 0x11
+ * in idetape_issue_packet_command (did effect
+ * debugging output only)
+ * AJN-2) Added more debugging output, and
+ * added ide-tape: where missing. I would also
+ * like to add tape->name where possible
+ * AJN-3) Added different debug_level's
+ * via /proc/ide/hdc/settings
+ * "debug_level" determines amount of debugging output;
+ * can be changed using /proc/ide/hdx/settings
+ * 0 : almost no debugging output
+ * 1 : 0+output errors only
+ * 2 : 1+output all sensekey/asc
+ * 3 : 2+follow all chrdev related procedures
+ * 4 : 3+follow all procedures
+ * 5 : 4+include pc_stack rq_stack info
+ * 6 : 5+USE_COUNT updates
+ * AJN-4) Fixed timeout for retension in idetape_queue_pc_tail
+ * from 5 to 10 minutes
+ * AJN-5) Changed maximum number of blocks to skip when
+ * reading tapes with multiple consecutive write
+ * errors from 100 to 1000 in idetape_get_logical_blk
+ * Proposed changes to code:
+ * 1) output "logical_blk_num" via /proc
+ * 2) output "current_operation" via /proc
+ * 3) Either solve or document the fact that `mt rewind' is
+ * required after reading from /dev/nhtx to be
+ * able to rmmod the idetape module;
+ * Also, sometimes an application finishes but the
+ * device remains `busy' for some time. Same cause ?
+ * Proposed changes to release-notes:
+ * 4) write a simple `quickstart' section in the
+ * release notes; I volunteer if you don't want to
+ * 5) include a pointer to video4linux in the doc
+ * to stimulate video applications
+ * 6) release notes lines 331 and 362: explain what happens
+ * if the application data rate is higher than 1100 KB/s;
+ * similar approach to lower-than-500 kB/s ?
+ * 7) 6.6 Comparison; wouldn't it be better to allow different
+ * strategies for read and write ?
+ * Wouldn't it be better to control the tape buffer
+ * contents instead of the bandwidth ?
+ * 8) line 536: replace will by would (if I understand
+ * this section correctly, a hypothetical and unwanted situation
+ * is being described)
+ * Ver 1.16f Dec 15 99 Change place of the secondary OnStream header frames.
+ * Ver 1.17 Nov 2000 / Jan 2001 Marcel Mol, marcel@mesa.nl
+ * - Add idetape_onstream_mode_sense_tape_parameter_page
+ * function to get tape capacity in frames: tape->capacity.
+ * - Add support for DI-50 drives( or any DI- drive).
+ * - 'workaround' for read error/blank block around block 3000.
+ * - Implement Early warning for end of media for Onstream.
+ * - Cosmetic code changes for readability.
+ * - Idetape_position_tape should not use SKIP bit during
+ * Onstream read recovery.
+ * - Add capacity, logical_blk_num and first/last_frame_position
+ * to /proc/ide/hd?/settings.
+ * - Module use count was gone in the Linux 2.4 driver.
+ * Ver 1.17a Apr 2001 Willem Riede osst@riede.org
+ * - Get drive's actual block size from mode sense block descriptor
+ * - Limit size of pipeline
+ * Ver 1.17b Oct 2002 Alan Stern <stern@rowland.harvard.edu>
+ * Changed IDETAPE_MIN_PIPELINE_STAGES to 1 and actually used
+ * it in the code!
+ * Actually removed aborted stages in idetape_abort_pipeline
+ * instead of just changing the command code.
+ * Made the transfer byte count for Request Sense equal to the
+ * actual length of the data transfer.
+ * Changed handling of partial data transfers: they do not
+ * cause DMA errors.
+ * Moved initiation of DMA transfers to the correct place.
+ * Removed reference to unallocated memory.
+ * Made __idetape_discard_read_pipeline return the number of
+ * sectors skipped, not the number of stages.
+ * Replaced errant kfree() calls with __idetape_kfree_stage().
+ * Fixed off-by-one error in testing the pipeline length.
+ * Fixed handling of filemarks in the read pipeline.
+ * Small code optimization for MTBSF and MTBSFM ioctls.
+ * Don't try to unlock the door during device close if is
+ * already unlocked!
+ * Cosmetic fixes to miscellaneous debugging output messages.
+ * Set the minimum /proc/ide/hd?/settings values for "pipeline",
+ * "pipeline_min", and "pipeline_max" to 1.
+ *
+ * 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.
+ */
+
+
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index f159e7b..552cfed 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -1,424 +1,18 @@
/*
+ * IDE ATAPI streaming tape driver.
+ *
* Copyright (C) 1995-1999 Gadi Oxman <gadio@netvision.net.il>
* Copyright (C) 2003-2005 Bartlomiej Zolnierkiewicz
*
- * $Header$
- *
* This driver was constructed as a student project in the software laboratory
* of the faculty of electrical engineering in the Technion - Israel's
* Institute Of Technology, with the guide of Avner Lottem and Dr. Ilana David.
*
* It is hereby placed under the terms of the GNU general public license.
* (See linux/COPYING).
- */
-
-/*
- * IDE ATAPI streaming tape driver.
- *
- * This driver is a part of the Linux ide driver and works in co-operation
- * with linux/drivers/block/ide.c.
- *
- * 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.
- * ...
- *
- * Run linux/scripts/MAKEDEV.ide to create the above entries.
- *
- * 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.
- *
- * Ver 0.1 Nov 1 95 Pre-working code :-)
- * Ver 0.2 Nov 23 95 A short backup (few megabytes) and restore procedure
- * was successful ! (Using tar cvf ... on the block
- * device interface).
- * A longer backup resulted in major swapping, bad
- * overall Linux performance and eventually failed as
- * we received non serial read-ahead requests from the
- * buffer cache.
- * Ver 0.3 Nov 28 95 Long backups are now possible, thanks to the
- * character device interface. Linux's responsiveness
- * and performance doesn't seem to be much affected
- * from the background backup procedure.
- * Some general mtio.h magnetic tape operations are
- * now supported by our character device. As a result,
- * popular tape utilities are starting to work with
- * ide tapes :-)
- * The following configurations were tested:
- * 1. An IDE ATAPI TAPE shares the same interface
- * and irq with an IDE ATAPI CDROM.
- * 2. An IDE ATAPI TAPE shares the same interface
- * and irq with a normal IDE disk.
- * Both configurations seemed to work just fine !
- * However, to be on the safe side, it is meanwhile
- * recommended to give the IDE TAPE its own interface
- * and irq.
- * The one thing which needs to be done here is to
- * add a "request postpone" feature to ide.c,
- * so that we won't have to wait for the tape to finish
- * performing a long media access (DSC) request (such
- * as a rewind) before we can access the other device
- * on the same interface. This effect doesn't disturb
- * normal operation most of the time because read/write
- * requests are relatively fast, and once we are
- * performing one tape r/w request, a lot of requests
- * from the other device can be queued and ide.c will
- * service all of them after this single tape request.
- * Ver 1.0 Dec 11 95 Integrated into Linux 1.3.46 development tree.
- * On each read / write request, we now ask the drive
- * if we can transfer a constant number of bytes
- * (a parameter of the drive) only to its buffers,
- * without causing actual media access. If we can't,
- * we just wait until we can by polling the DSC bit.
- * This ensures that while we are not transferring
- * more bytes than the constant referred to above, the
- * interrupt latency will not become too high and
- * we won't cause an interrupt timeout, as happened
- * occasionally in the previous version.
- * While polling for DSC, the current request is
- * postponed and ide.c is free to handle requests from
- * the other device. This is handled transparently to
- * ide.c. The hwgroup locking method which was used
- * in the previous version was removed.
- * Use of new general features which are provided by
- * ide.c for use with atapi devices.
- * (Programming done by Mark Lord)
- * Few potential bug fixes (Again, suggested by Mark)
- * Single character device data transfers are now
- * not limited in size, as they were before.
- * We are asking the tape about its recommended
- * transfer unit and send a larger data transfer
- * as several transfers of the above size.
- * For best results, use an integral number of this
- * basic unit (which is shown during driver
- * initialization). I will soon add an ioctl to get
- * this important parameter.
- * Our data transfer buffer is allocated on startup,
- * rather than before each data transfer. This should
- * ensure that we will indeed have a data buffer.
- * Ver 1.1 Dec 14 95 Fixed random problems which occurred when the tape
- * shared an interface with another device.
- * (poll_for_dsc was a complete mess).
- * Removed some old (non-active) code which had
- * to do with supporting buffer cache originated
- * requests.
- * The block device interface can now be opened, so
- * that general ide driver features like the unmask
- * interrupts flag can be selected with an ioctl.
- * This is the only use of the block device interface.
- * New fast pipelined operation mode (currently only on
- * writes). When using the pipelined mode, the
- * throughput can potentially reach the maximum
- * tape supported throughput, regardless of the
- * user backup program. On my tape drive, it sometimes
- * boosted performance by a factor of 2. Pipelined
- * mode is enabled by default, but since it has a few
- * downfalls as well, you may want to disable it.
- * A short explanation of the pipelined operation mode
- * is available below.
- * Ver 1.2 Jan 1 96 Eliminated pipelined mode race condition.
- * Added pipeline read mode. As a result, restores
- * are now as fast as backups.
- * Optimized shared interface behavior. The new behavior
- * typically results in better IDE bus efficiency and
- * higher tape throughput.
- * Pre-calculation of the expected read/write request
- * service time, based on the tape's parameters. In
- * the pipelined operation mode, this allows us to
- * adjust our polling frequency to a much lower value,
- * and thus to dramatically reduce our load on Linux,
- * without any decrease in performance.
- * Implemented additional mtio.h operations.
- * The recommended user block size is returned by
- * the MTIOCGET ioctl.
- * Additional minor changes.
- * Ver 1.3 Feb 9 96 Fixed pipelined read mode bug which prevented the
- * use of some block sizes during a restore procedure.
- * The character device interface will now present a
- * continuous view of the media - any mix of block sizes
- * during a backup/restore procedure is supported. The
- * driver will buffer the requests internally and
- * convert them to the tape's recommended transfer
- * unit, making performance almost independent of the
- * chosen user block size.
- * Some improvements in error recovery.
- * By cooperating with ide-dma.c, bus mastering DMA can
- * now sometimes be used with IDE tape drives as well.
- * Bus mastering DMA has the potential to dramatically
- * reduce the CPU's overhead when accessing the device,
- * and can be enabled by using hdparm -d1 on the tape's
- * block device interface. For more info, read the
- * comments in ide-dma.c.
- * Ver 1.4 Mar 13 96 Fixed serialize support.
- * Ver 1.5 Apr 12 96 Fixed shared interface operation, broken in 1.3.85.
- * Fixed pipelined read mode inefficiency.
- * Fixed nasty null dereferencing bug.
- * Ver 1.6 Aug 16 96 Fixed FPU usage in the driver.
- * Fixed end of media bug.
- * Ver 1.7 Sep 10 96 Minor changes for the CONNER CTT8000-A model.
- * Ver 1.8 Sep 26 96 Attempt to find a better balance between good
- * interactive response and high system throughput.
- * Ver 1.9 Nov 5 96 Automatically cross encountered filemarks rather
- * than requiring an explicit FSF command.
- * Abort pending requests at end of media.
- * MTTELL was sometimes returning incorrect results.
- * Return the real block size in the MTIOCGET ioctl.
- * Some error recovery bug fixes.
- * Ver 1.10 Nov 5 96 Major reorganization.
- * Reduced CPU overhead a bit by eliminating internal
- * bounce buffers.
- * Added module support.
- * Added multiple tape drives support.
- * Added partition support.
- * Rewrote DSC handling.
- * Some portability fixes.
- * Removed ide-tape.h.
- * Additional minor changes.
- * Ver 1.11 Dec 2 96 Bug fix in previous DSC timeout handling.
- * Use ide_stall_queue() for DSC overlap.
- * Use the maximum speed rather than the current speed
- * to compute the request service time.
- * Ver 1.12 Dec 7 97 Fix random memory overwriting and/or last block data
- * corruption, which could occur if the total number
- * of bytes written to the tape was not an integral
- * number of tape blocks.
- * Add support for INTERRUPT DRQ devices.
- * Ver 1.13 Jan 2 98 Add "speed == 0" work-around for HP COLORADO 5GB
- * Ver 1.14 Dec 30 98 Partial fixes for the Sony/AIWA tape drives.
- * Replace cli()/sti() with hwgroup spinlocks.
- * Ver 1.15 Mar 25 99 Fix SMP race condition by replacing hwgroup
- * spinlock with private per-tape spinlock.
- * Ver 1.16 Sep 1 99 Add OnStream tape support.
- * Abort read pipeline on EOD.
- * Wait for the tape to become ready in case it returns
- * "in the process of becoming ready" on open().
- * Fix zero padding of the last written block in
- * case the tape block size is larger than PAGE_SIZE.
- * Decrease the default disconnection time to tn.
- * Ver 1.16e Oct 3 99 Minor fixes.
- * Ver 1.16e1 Oct 13 99 Patches by Arnold Niessen,
- * niessen@iae.nl / arnold.niessen@philips.com
- * GO-1) Undefined code in idetape_read_position
- * according to Gadi's email
- * AJN-1) Minor fix asc == 11 should be asc == 0x11
- * in idetape_issue_packet_command (did effect
- * debugging output only)
- * AJN-2) Added more debugging output, and
- * added ide-tape: where missing. I would also
- * like to add tape->name where possible
- * AJN-3) Added different debug_level's
- * via /proc/ide/hdc/settings
- * "debug_level" determines amount of debugging output;
- * can be changed using /proc/ide/hdx/settings
- * 0 : almost no debugging output
- * 1 : 0+output errors only
- * 2 : 1+output all sensekey/asc
- * 3 : 2+follow all chrdev related procedures
- * 4 : 3+follow all procedures
- * 5 : 4+include pc_stack rq_stack info
- * 6 : 5+USE_COUNT updates
- * AJN-4) Fixed timeout for retension in idetape_queue_pc_tail
- * from 5 to 10 minutes
- * AJN-5) Changed maximum number of blocks to skip when
- * reading tapes with multiple consecutive write
- * errors from 100 to 1000 in idetape_get_logical_blk
- * Proposed changes to code:
- * 1) output "logical_blk_num" via /proc
- * 2) output "current_operation" via /proc
- * 3) Either solve or document the fact that `mt rewind' is
- * required after reading from /dev/nhtx to be
- * able to rmmod the idetape module;
- * Also, sometimes an application finishes but the
- * device remains `busy' for some time. Same cause ?
- * Proposed changes to release-notes:
- * 4) write a simple `quickstart' section in the
- * release notes; I volunteer if you don't want to
- * 5) include a pointer to video4linux in the doc
- * to stimulate video applications
- * 6) release notes lines 331 and 362: explain what happens
- * if the application data rate is higher than 1100 KB/s;
- * similar approach to lower-than-500 kB/s ?
- * 7) 6.6 Comparison; wouldn't it be better to allow different
- * strategies for read and write ?
- * Wouldn't it be better to control the tape buffer
- * contents instead of the bandwidth ?
- * 8) line 536: replace will by would (if I understand
- * this section correctly, a hypothetical and unwanted situation
- * is being described)
- * Ver 1.16f Dec 15 99 Change place of the secondary OnStream header frames.
- * Ver 1.17 Nov 2000 / Jan 2001 Marcel Mol, marcel@mesa.nl
- * - Add idetape_onstream_mode_sense_tape_parameter_page
- * function to get tape capacity in frames: tape->capacity.
- * - Add support for DI-50 drives( or any DI- drive).
- * - 'workaround' for read error/blank block around block 3000.
- * - Implement Early warning for end of media for Onstream.
- * - Cosmetic code changes for readability.
- * - Idetape_position_tape should not use SKIP bit during
- * Onstream read recovery.
- * - Add capacity, logical_blk_num and first/last_frame_position
- * to /proc/ide/hd?/settings.
- * - Module use count was gone in the Linux 2.4 driver.
- * Ver 1.17a Apr 2001 Willem Riede osst@riede.org
- * - Get drive's actual block size from mode sense block descriptor
- * - Limit size of pipeline
- * Ver 1.17b Oct 2002 Alan Stern <stern@rowland.harvard.edu>
- * Changed IDETAPE_MIN_PIPELINE_STAGES to 1 and actually used
- * it in the code!
- * Actually removed aborted stages in idetape_abort_pipeline
- * instead of just changing the command code.
- * Made the transfer byte count for Request Sense equal to the
- * actual length of the data transfer.
- * Changed handling of partial data transfers: they do not
- * cause DMA errors.
- * Moved initiation of DMA transfers to the correct place.
- * Removed reference to unallocated memory.
- * Made __idetape_discard_read_pipeline return the number of
- * sectors skipped, not the number of stages.
- * Replaced errant kfree() calls with __idetape_kfree_stage().
- * Fixed off-by-one error in testing the pipeline length.
- * Fixed handling of filemarks in the read pipeline.
- * Small code optimization for MTBSF and MTBSFM ioctls.
- * Don't try to unlock the door during device close if is
- * already unlocked!
- * Cosmetic fixes to miscellaneous debugging output messages.
- * Set the minimum /proc/ide/hd?/settings values for "pipeline",
- * "pipeline_min", and "pipeline_max" to 1.
- *
- * 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.
+ * For a historical changelog see
+ * Documentation/ide/ChangeLog.ide-tape.1995-2002
*/
#define IDETAPE_VERSION "1.19"
--
1.5.3.7
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/32] ide-tape: remove dead code
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
2008-01-27 8:41 ` [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002 Borislav Petkov
@ 2008-01-27 8:41 ` Borislav Petkov
2008-01-27 8:41 ` [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t Borislav Petkov
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
drivers/ide/ide-tape.c | 34 ----------------------------------
1 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 552cfed..3bedeb8 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -784,21 +784,6 @@ typedef struct {
__u8 medium_type; /* Medium Type */
__u8 dsp; /* Device Specific Parameter */
__u8 bdl; /* Block Descriptor Length */
-#if 0
- /* data transfer page */
- __u8 page_code :6;
- __u8 reserved0_6 :1;
- __u8 ps :1; /* parameters saveable */
- __u8 page_length; /* page Length == 0x02 */
- __u8 reserved2;
- __u8 read32k :1; /* 32k blk size (data only) */
- __u8 read32k5 :1; /* 32.5k blk size (data&AUX) */
- __u8 reserved3_23 :2;
- __u8 write32k :1; /* 32k blk size (data only) */
- __u8 write32k5 :1; /* 32.5k blk size (data&AUX) */
- __u8 reserved3_6 :1;
- __u8 streaming :1; /* streaming mode enable */
-#endif
} idetape_mode_parameter_header_t;
/*
@@ -2006,12 +1991,6 @@ static ide_startstop_t idetape_do_request(ide_drive_t *drive,
u8 stat;
#if IDETAPE_DEBUG_LOG
-#if 0
- if (tape->debug_level >= 5)
- printk(KERN_INFO "ide-tape: %d, "
- "dev: %s, cmd: %ld, errors: %d\n",
- rq->rq_disk->disk_name, rq->cmd[0], rq->errors);
-#endif
if (tape->debug_level >= 2)
printk(KERN_INFO "ide-tape: sector: %ld, "
"nr_sectors: %ld, current_nr_sectors: %d\n",
@@ -2723,19 +2702,6 @@ static void idetape_create_rewind_cmd (ide_drive_t *drive, idetape_pc_t *pc)
pc->callback = &idetape_pc_callback;
}
-#if 0
-static void idetape_create_mode_select_cmd (idetape_pc_t *pc, int length)
-{
- idetape_init_pc(pc);
- set_bit(PC_WRITING, &pc->flags);
- pc->c[0] = IDETAPE_MODE_SELECT_CMD;
- pc->c[1] = 0x10;
- put_unaligned(htons(length), (unsigned short *) &pc->c[3]);
- pc->request_transfer = 255;
- pc->callback = &idetape_pc_callback;
-}
-#endif
-
static void idetape_create_erase_cmd (idetape_pc_t *pc)
{
idetape_init_pc(pc);
--
1.5.3.7
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
2008-01-27 8:41 ` [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002 Borislav Petkov
2008-01-27 8:41 ` [PATCH 2/32] ide-tape: remove dead code Borislav Petkov
@ 2008-01-27 8:41 ` Borislav Petkov
2008-01-27 15:19 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t Borislav Petkov
` (2 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
drivers/ide/ide-tape.c | 83 +++++++++++++++--------------------------------
1 files changed, 27 insertions(+), 56 deletions(-)
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 3bedeb8..173ac0d 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -333,32 +333,6 @@ typedef struct idetape_stage_s {
} idetape_stage_t;
/*
- * REQUEST SENSE packet command result - Data Format.
- */
-typedef struct {
- unsigned error_code :7; /* Current of deferred errors */
- unsigned valid :1; /* The information field conforms to QIC-157C */
- __u8 reserved1 :8; /* Segment Number - Reserved */
- unsigned sense_key :4; /* Sense Key */
- unsigned reserved2_4 :1; /* Reserved */
- unsigned ili :1; /* Incorrect Length Indicator */
- unsigned eom :1; /* End Of Medium */
- unsigned filemark :1; /* Filemark */
- __u32 information __attribute__ ((packed));
- __u8 asl; /* Additional sense length (n-7) */
- __u32 command_specific; /* Additional command specific information */
- __u8 asc; /* Additional Sense Code */
- __u8 ascq; /* Additional Sense Code Qualifier */
- __u8 replaceable_unit_code; /* Field Replaceable Unit Code */
- unsigned sk_specific1 :7; /* Sense Key Specific */
- unsigned sksv :1; /* Sense Key Specific information is valid */
- __u8 sk_specific2; /* Sense Key Specific */
- __u8 sk_specific3; /* Sense Key Specific */
- __u8 pad[2]; /* Padding to 20 bytes */
-} idetape_request_sense_result_t;
-
-
-/*
* Most of our global data which we need to save even as we leave the
* driver due to an interrupt or a timer event is stored in a variable
* of type idetape_tape_t, defined below.
@@ -512,9 +486,6 @@ typedef struct ide_tape_obj {
int avg_size;
int avg_speed;
- /* last sense information */
- idetape_request_sense_result_t sense;
-
char vendor_id[10];
char product_id[18];
char firmware_revision[6];
@@ -1025,67 +996,67 @@ static void idetape_init_pc (idetape_pc_t *pc)
}
/*
- * idetape_analyze_error is called on each failed packet command retry
- * to analyze the request sense. We currently do not utilize this
- * information.
+ * called on each failed packet command retry to analyze the request sense. We
+ * currently do not utilize this information.
*/
-static void idetape_analyze_error (ide_drive_t *drive, idetape_request_sense_result_t *result)
+static void idetape_analyze_error(ide_drive_t *drive, u8 *sense)
{
idetape_tape_t *tape = drive->driver_data;
idetape_pc_t *pc = tape->failed_pc;
- tape->sense = *result;
- tape->sense_key = result->sense_key;
- tape->asc = result->asc;
- tape->ascq = result->ascq;
+ tape->sense_key = sense[2] & 0xF;
+ tape->asc = sense[12];
+ tape->ascq = sense[13];
#if IDETAPE_DEBUG_LOG
/*
- * Without debugging, we only log an error if we decided to
- * give up retrying.
+ * Without debugging, we only log an error if we decided to give up
+ * retrying.
*/
if (tape->debug_level >= 1)
printk(KERN_INFO "ide-tape: pc = %x, sense key = %x, "
"asc = %x, ascq = %x\n",
- pc->c[0], result->sense_key,
- result->asc, result->ascq);
+ pc->c[0], tape->sense_key,
+ tape->asc, tape->ascq);
#endif /* IDETAPE_DEBUG_LOG */
- /*
- * Correct pc->actually_transferred by asking the tape.
- */
+ /* Correct pc->actually_transferred by asking the tape. */
if (test_bit(PC_DMA_ERROR, &pc->flags)) {
- pc->actually_transferred = pc->request_transfer - tape->tape_block_size * ntohl(get_unaligned(&result->information));
+ pc->actually_transferred = pc->request_transfer -
+ tape->tape_block_size *
+ ntohl(get_unaligned((u32 *)&sense[3]));
idetape_update_buffers(pc);
}
/*
- * If error was the result of a zero-length read or write command,
- * with sense key=5, asc=0x22, ascq=0, let it slide. Some drives
- * (i.e. Seagate STT3401A Travan) don't support 0-length read/writes.
+ * If error was the result of a zero-length read or write command, with
+ * sense key=5, asc=0x22, ascq=0, let it slide. Some drives (i.e.
+ * Seagate STT3401A Travan) don't support 0-length read/writes.
*/
if ((pc->c[0] == IDETAPE_READ_CMD || pc->c[0] == IDETAPE_WRITE_CMD)
- && pc->c[4] == 0 && pc->c[3] == 0 && pc->c[2] == 0) { /* length==0 */
- if (result->sense_key == 5) {
+ /* length==0 */
+ && pc->c[4] == 0 && pc->c[3] == 0 && pc->c[2] == 0) {
+ if (tape->sense_key == 5) {
/* don't report an error, everything's ok */
pc->error = 0;
/* don't retry read/write */
set_bit(PC_ABORT, &pc->flags);
}
}
- if (pc->c[0] == IDETAPE_READ_CMD && result->filemark) {
+ if (pc->c[0] == IDETAPE_READ_CMD && !!(sense[2] & 0x80)) {
pc->error = IDETAPE_ERROR_FILEMARK;
set_bit(PC_ABORT, &pc->flags);
}
if (pc->c[0] == IDETAPE_WRITE_CMD) {
- if (result->eom ||
- (result->sense_key == 0xd && result->asc == 0x0 &&
- result->ascq == 0x2)) {
+ if (!!(sense[2] & 0x40) ||
+ (tape->sense_key == 0xd &&
+ tape->asc == 0x0 &&
+ tape->ascq == 0x2)) {
pc->error = IDETAPE_ERROR_EOD;
set_bit(PC_ABORT, &pc->flags);
}
}
if (pc->c[0] == IDETAPE_READ_CMD || pc->c[0] == IDETAPE_WRITE_CMD) {
- if (result->sense_key == 8) {
+ if (tape->sense_key == 8) {
pc->error = IDETAPE_ERROR_EOD;
set_bit(PC_ABORT, &pc->flags);
}
@@ -1327,7 +1298,7 @@ static ide_startstop_t idetape_request_sense_callback (ide_drive_t *drive)
printk(KERN_INFO "ide-tape: Reached idetape_request_sense_callback\n");
#endif /* IDETAPE_DEBUG_LOG */
if (!tape->pc->error) {
- idetape_analyze_error(drive, (idetape_request_sense_result_t *) tape->pc->buffer);
+ idetape_analyze_error(drive, tape->pc->buffer);
idetape_end_request(drive, 1, 0);
} else {
printk(KERN_ERR "ide-tape: Error in REQUEST SENSE itself - Aborting request!\n");
--
1.5.3.7
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
` (2 preceding siblings ...)
2008-01-27 8:41 ` [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t Borislav Petkov
@ 2008-01-27 8:41 ` Borislav Petkov
2008-01-27 15:25 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 5/32] ide-tape: remove IDETAPE_DEBUG_INFO Borislav Petkov
2008-01-27 19:45 ` [PATCH 0/32] ide-tape redux v1 Bartlomiej Zolnierkiewicz
5 siblings, 1 reply; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
drivers/ide/ide-tape.c | 40 +++++++++++++++-------------------------
1 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 173ac0d..0542b07 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -748,16 +748,6 @@ typedef struct {
#define IDETAPE_BUFFER_FILLING_PAGE 0x33
/*
- * Mode Parameter Header for the MODE SENSE packet command
- */
-typedef struct {
- __u8 mode_data_length; /* Length of the following data transfer */
- __u8 medium_type; /* Medium Type */
- __u8 dsp; /* Device Specific Parameter */
- __u8 bdl; /* Block Descriptor Length */
-} idetape_mode_parameter_header_t;
-
-/*
* Mode Parameter Block Descriptor the MODE SENSE packet command
*
* Support for block descriptors is optional.
@@ -3916,9 +3906,8 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
{
idetape_tape_t *tape = drive->driver_data;
idetape_pc_t pc;
- idetape_mode_parameter_header_t *header;
idetape_capabilities_page_t *capabilities;
-
+
idetape_create_mode_sense_cmd(&pc, IDETAPE_CAPABILITIES_PAGE);
if (idetape_queue_pc_tail(drive, &pc)) {
printk(KERN_ERR "ide-tape: Can't get tape parameters - assuming some default values\n");
@@ -3928,8 +3917,8 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
tape->capabilities.buffer_size = 6 * 52;
return;
}
- header = (idetape_mode_parameter_header_t *) pc.buffer;
- capabilities = (idetape_capabilities_page_t *) (pc.buffer + sizeof(idetape_mode_parameter_header_t) + header->bdl);
+ capabilities = (idetape_capabilities_page_t *)
+ (pc.buffer + 4 + pc.buffer[3]);
capabilities->max_speed = ntohs(capabilities->max_speed);
capabilities->ctl = ntohs(capabilities->ctl);
@@ -3954,11 +3943,13 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
#if IDETAPE_DEBUG_INFO
printk(KERN_INFO "ide-tape: Dumping the results of the MODE SENSE packet command\n");
printk(KERN_INFO "ide-tape: Mode Parameter Header:\n");
- printk(KERN_INFO "ide-tape: Mode Data Length - %d\n",header->mode_data_length);
- printk(KERN_INFO "ide-tape: Medium Type - %d\n",header->medium_type);
- printk(KERN_INFO "ide-tape: Device Specific Parameter - %d\n",header->dsp);
- printk(KERN_INFO "ide-tape: Block Descriptor Length - %d\n",header->bdl);
-
+ printk(KERN_INFO "ide-tape: Mode Data Length - %d\n", pc.buffer[0]);
+ printk(KERN_INFO "ide-tape: Medium Type - %d\n", pc.buffer[1]);
+ printk(KERN_INFO "ide-tape: Device Specific Parameter - %d\n",
+ pc.buffer[2]);
+ printk(KERN_INFO "ide-tape: Block Descriptor Length - %d\n",
+ pc.buffer[3]);
+
printk(KERN_INFO "ide-tape: Capabilities and Mechanical Status Page:\n");
printk(KERN_INFO "ide-tape: Page code - %d\n",capabilities->page_code);
printk(KERN_INFO "ide-tape: Page length - %d\n",capabilities->page_length);
@@ -3977,7 +3968,8 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
printk(KERN_INFO "ide-tape: Supports 32768 bytes block size / Restricted byte count for PIO transfers - %s\n",capabilities->blk32768 ? "Yes":"No");
printk(KERN_INFO "ide-tape: Maximum supported speed in KBps - %d\n",capabilities->max_speed);
printk(KERN_INFO "ide-tape: Continuous transfer limits in blocks - %d\n",capabilities->ctl);
- printk(KERN_INFO "ide-tape: Current speed in KBps - %d\n",capabilities->speed);
+ printk(KERN_INFO "ide-tape: Current speed in KBps - %d\n",
+ capabilities->speed);
printk(KERN_INFO "ide-tape: Buffer size - %d\n",capabilities->buffer_size*512);
#endif /* IDETAPE_DEBUG_INFO */
}
@@ -3991,9 +3983,8 @@ static void idetape_get_blocksize_from_block_descriptor(ide_drive_t *drive)
idetape_tape_t *tape = drive->driver_data;
idetape_pc_t pc;
- idetape_mode_parameter_header_t *header;
idetape_parameter_block_descriptor_t *block_descrp;
-
+
idetape_create_mode_sense_cmd(&pc, IDETAPE_BLOCK_DESCRIPTOR);
if (idetape_queue_pc_tail(drive, &pc)) {
printk(KERN_ERR "ide-tape: Can't get block descriptor\n");
@@ -4003,10 +3994,9 @@ static void idetape_get_blocksize_from_block_descriptor(ide_drive_t *drive)
}
return;
}
- header = (idetape_mode_parameter_header_t *) pc.buffer;
- block_descrp = (idetape_parameter_block_descriptor_t *) (pc.buffer + sizeof(idetape_mode_parameter_header_t));
+ block_descrp = (idetape_parameter_block_descriptor_t *) pc.buffer + 4;
tape->tape_block_size =( block_descrp->length[0]<<16) + (block_descrp->length[1]<<8) + block_descrp->length[2];
- tape->drv_write_prot = (header->dsp & 0x80) >> 7;
+ tape->drv_write_prot = (pc.buffer[2] & 0x80) >> 7;
#if IDETAPE_DEBUG_INFO
printk(KERN_INFO "ide-tape: Adjusted block size - %d\n", tape->tape_block_size);
--
1.5.3.7
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 5/32] ide-tape: remove IDETAPE_DEBUG_INFO
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
` (3 preceding siblings ...)
2008-01-27 8:41 ` [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t Borislav Petkov
@ 2008-01-27 8:41 ` Borislav Petkov
2008-01-27 19:45 ` [PATCH 0/32] ide-tape redux v1 Bartlomiej Zolnierkiewicz
5 siblings, 0 replies; 14+ messages in thread
From: Borislav Petkov @ 2008-01-27 8:41 UTC (permalink / raw)
To: bzolnier; +Cc: linux-kernel, linux-ide, Borislav Petkov
The device capabilities are probed for during device initialization so this
info is available through proc/ioctl() und it is redundant here.
Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
---
drivers/ide/ide-tape.c | 74 ------------------------------------------------
1 files changed, 0 insertions(+), 74 deletions(-)
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index 0542b07..dbececc 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -106,7 +106,6 @@ typedef struct os_dat_s {
/*
* The following are used to debug the driver:
*
- * Setting IDETAPE_DEBUG_INFO to 1 will report device capabilities.
* Setting IDETAPE_DEBUG_LOG to 1 will log driver flow control.
* Setting IDETAPE_DEBUG_BUGS to 1 will enable self-sanity checks in
* some places.
@@ -121,7 +120,6 @@ typedef struct os_dat_s {
* is verified to be stable enough. This will make it much more
* esthetic.
*/
-#define IDETAPE_DEBUG_INFO 0
#define IDETAPE_DEBUG_LOG 0
#define IDETAPE_DEBUG_BUGS 1
@@ -3817,41 +3815,6 @@ static int idetape_identify_device (ide_drive_t *drive)
*((unsigned short *) &gcw) = id->config;
-#if IDETAPE_DEBUG_INFO
- printk(KERN_INFO "ide-tape: Dumping ATAPI Identify Device tape parameters\n");
- printk(KERN_INFO "ide-tape: Protocol Type: ");
- switch (gcw.protocol) {
- case 0: case 1: printk("ATA\n");break;
- case 2: printk("ATAPI\n");break;
- case 3: printk("Reserved (Unknown to ide-tape)\n");break;
- }
- printk(KERN_INFO "ide-tape: Device Type: %x - ",gcw.device_type);
- switch (gcw.device_type) {
- case 0: printk("Direct-access Device\n");break;
- case 1: printk("Streaming Tape Device\n");break;
- case 2: case 3: case 4: printk("Reserved\n");break;
- case 5: printk("CD-ROM Device\n");break;
- case 6: printk("Reserved\n");
- case 7: printk("Optical memory Device\n");break;
- case 0x1f: printk("Unknown or no Device type\n");break;
- default: printk("Reserved\n");
- }
- printk(KERN_INFO "ide-tape: Removable: %s",gcw.removable ? "Yes\n":"No\n");
- printk(KERN_INFO "ide-tape: Command Packet DRQ Type: ");
- switch (gcw.drq_type) {
- case 0: printk("Microprocessor DRQ\n");break;
- case 1: printk("Interrupt DRQ\n");break;
- case 2: printk("Accelerated DRQ\n");break;
- case 3: printk("Reserved\n");break;
- }
- printk(KERN_INFO "ide-tape: Command Packet Size: ");
- switch (gcw.packet_size) {
- case 0: printk("12 bytes\n");break;
- case 1: printk("16 bytes\n");break;
- default: printk("Reserved\n");break;
- }
-#endif /* IDETAPE_DEBUG_INFO */
-
/* Check that we can support this device */
if (gcw.protocol !=2 )
@@ -3939,39 +3902,6 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
tape->tape_block_size = 512;
else if (capabilities->blk1024)
tape->tape_block_size = 1024;
-
-#if IDETAPE_DEBUG_INFO
- printk(KERN_INFO "ide-tape: Dumping the results of the MODE SENSE packet command\n");
- printk(KERN_INFO "ide-tape: Mode Parameter Header:\n");
- printk(KERN_INFO "ide-tape: Mode Data Length - %d\n", pc.buffer[0]);
- printk(KERN_INFO "ide-tape: Medium Type - %d\n", pc.buffer[1]);
- printk(KERN_INFO "ide-tape: Device Specific Parameter - %d\n",
- pc.buffer[2]);
- printk(KERN_INFO "ide-tape: Block Descriptor Length - %d\n",
- pc.buffer[3]);
-
- printk(KERN_INFO "ide-tape: Capabilities and Mechanical Status Page:\n");
- printk(KERN_INFO "ide-tape: Page code - %d\n",capabilities->page_code);
- printk(KERN_INFO "ide-tape: Page length - %d\n",capabilities->page_length);
- printk(KERN_INFO "ide-tape: Read only - %s\n",capabilities->ro ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports reverse space - %s\n",capabilities->sprev ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports erase initiated formatting - %s\n",capabilities->efmt ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports QFA two Partition format - %s\n",capabilities->qfa ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports locking the medium - %s\n",capabilities->lock ? "Yes":"No");
- printk(KERN_INFO "ide-tape: The volume is currently locked - %s\n",capabilities->locked ? "Yes":"No");
- printk(KERN_INFO "ide-tape: The device defaults in the prevent state - %s\n",capabilities->prevent ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports ejecting the medium - %s\n",capabilities->eject ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports error correction - %s\n",capabilities->ecc ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports data compression - %s\n",capabilities->cmprs ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports 512 bytes block size - %s\n",capabilities->blk512 ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports 1024 bytes block size - %s\n",capabilities->blk1024 ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Supports 32768 bytes block size / Restricted byte count for PIO transfers - %s\n",capabilities->blk32768 ? "Yes":"No");
- printk(KERN_INFO "ide-tape: Maximum supported speed in KBps - %d\n",capabilities->max_speed);
- printk(KERN_INFO "ide-tape: Continuous transfer limits in blocks - %d\n",capabilities->ctl);
- printk(KERN_INFO "ide-tape: Current speed in KBps - %d\n",
- capabilities->speed);
- printk(KERN_INFO "ide-tape: Buffer size - %d\n",capabilities->buffer_size*512);
-#endif /* IDETAPE_DEBUG_INFO */
}
/*
@@ -3997,10 +3927,6 @@ static void idetape_get_blocksize_from_block_descriptor(ide_drive_t *drive)
block_descrp = (idetape_parameter_block_descriptor_t *) pc.buffer + 4;
tape->tape_block_size =( block_descrp->length[0]<<16) + (block_descrp->length[1]<<8) + block_descrp->length[2];
tape->drv_write_prot = (pc.buffer[2] & 0x80) >> 7;
-
-#if IDETAPE_DEBUG_INFO
- printk(KERN_INFO "ide-tape: Adjusted block size - %d\n", tape->tape_block_size);
-#endif /* IDETAPE_DEBUG_INFO */
}
#ifdef CONFIG_IDE_PROC_FS
--
1.5.3.7
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002
2008-01-27 8:41 ` [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002 Borislav Petkov
@ 2008-01-27 15:18 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-27 15:18 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, linux-ide
On Sunday 27 January 2008, Borislav Petkov wrote:
> Also, cleanup whitespace and update comments.
>
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
applied with some changes
> ---
> Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++++++++++++++++++++++
> drivers/ide/ide-tape.c | 414 +-----------------------
> 2 files changed, 409 insertions(+), 410 deletions(-)
>
> diff --git a/Documentation/ide/ChangeLog.ide-tape.1995-2002 b/Documentation/ide/ChangeLog.ide-tape.1995-2002
> new file mode 100644
> index 0000000..e406762
> --- /dev/null
> +++ b/Documentation/ide/ChangeLog.ide-tape.1995-2002
> @@ -0,0 +1,405 @@
> +/*
> + * IDE ATAPI streaming tape driver.
> + *
> + * This driver is a part of the Linux ide driver and works in co-operation
> + * with drivers/block/ide.c.
I removed incorrect reference to drivers/block/ide.c
> + * 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.
the above is not the part of the changelog
[...]
> + * 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!
[...]
ditto
> + * 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.
> + */
ditto
All of the above comments got moved to Documentation/ide/ide-tape.txt.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t
2008-01-27 8:41 ` [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t Borislav Petkov
@ 2008-01-27 15:19 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-27 15:19 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, linux-ide
On Sunday 27 January 2008, Borislav Petkov wrote:
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
> ---
> drivers/ide/ide-tape.c | 83 +++++++++++++++--------------------------------
> 1 files changed, 27 insertions(+), 56 deletions(-)
applied with minor changes
> diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
> index 3bedeb8..173ac0d 100644
> --- a/drivers/ide/ide-tape.c
> +++ b/drivers/ide/ide-tape.c
[...]
> /*
> - * If error was the result of a zero-length read or write command,
> - * with sense key=5, asc=0x22, ascq=0, let it slide. Some drives
> - * (i.e. Seagate STT3401A Travan) don't support 0-length read/writes.
> + * If error was the result of a zero-length read or write command, with
> + * sense key=5, asc=0x22, ascq=0, let it slide. Some drives (i.e.
> + * Seagate STT3401A Travan) don't support 0-length read/writes.
> */
This chunk is unnecessary, I dropped it.
> if ((pc->c[0] == IDETAPE_READ_CMD || pc->c[0] == IDETAPE_WRITE_CMD)
> - && pc->c[4] == 0 && pc->c[3] == 0 && pc->c[2] == 0) { /* length==0 */
> - if (result->sense_key == 5) {
> + /* length==0 */
> + && pc->c[4] == 0 && pc->c[3] == 0 && pc->c[2] == 0) {
> + if (tape->sense_key == 5) {
> /* don't report an error, everything's ok */
> pc->error = 0;
> /* don't retry read/write */
> set_bit(PC_ABORT, &pc->flags);
> }
> }
> - if (pc->c[0] == IDETAPE_READ_CMD && result->filemark) {
> + if (pc->c[0] == IDETAPE_READ_CMD && !!(sense[2] & 0x80)) {
needless "!!" removed
> pc->error = IDETAPE_ERROR_FILEMARK;
> set_bit(PC_ABORT, &pc->flags);
> }
> if (pc->c[0] == IDETAPE_WRITE_CMD) {
> - if (result->eom ||
> - (result->sense_key == 0xd && result->asc == 0x0 &&
> - result->ascq == 0x2)) {
> + if (!!(sense[2] & 0x40) ||
ditto
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t
2008-01-27 8:41 ` [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t Borislav Petkov
@ 2008-01-27 15:25 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-27 15:25 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, linux-ide
On Sunday 27 January 2008, Borislav Petkov wrote:
> Signed-off-by: Borislav Petkov <bbpetkov@yahoo.de>
applied with some changes
> ---
> drivers/ide/ide-tape.c | 40 +++++++++++++++-------------------------
> 1 files changed, 15 insertions(+), 25 deletions(-)
[...]
> @@ -3977,7 +3968,8 @@ static void idetape_get_mode_sense_results (ide_drive_t *drive)
> printk(KERN_INFO "ide-tape: Supports 32768 bytes block size / Restricted byte count for PIO transfers - %s\n",capabilities->blk32768 ? "Yes":"No");
> printk(KERN_INFO "ide-tape: Maximum supported speed in KBps - %d\n",capabilities->max_speed);
> printk(KERN_INFO "ide-tape: Continuous transfer limits in blocks - %d\n",capabilities->ctl);
> - printk(KERN_INFO "ide-tape: Current speed in KBps - %d\n",capabilities->speed);
> + printk(KERN_INFO "ide-tape: Current speed in KBps - %d\n",
> + capabilities->speed);
> printk(KERN_INFO "ide-tape: Buffer size - %d\n",capabilities->buffer_size*512);
> #endif /* IDETAPE_DEBUG_INFO */
> }
this code goes away in patch #5 so I dropped this chunk
[...]
> @@ -4003,10 +3994,9 @@ static void idetape_get_blocksize_from_block_descriptor(ide_drive_t *drive)
> }
> return;
> }
> - header = (idetape_mode_parameter_header_t *) pc.buffer;
> - block_descrp = (idetape_parameter_block_descriptor_t *) (pc.buffer + sizeof(idetape_mode_parameter_header_t));
> + block_descrp = (idetape_parameter_block_descriptor_t *) pc.buffer + 4;
these brackets _are_ needed
[ block_descrp is of 'idetape_parameter_block_descriptor_t *' type so without
brackets +4 would mean + 4 * sizeof(idetape_parameter_block_descriptor_t) ]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/32] ide-tape redux v1
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
` (4 preceding siblings ...)
2008-01-27 8:41 ` [PATCH 5/32] ide-tape: remove IDETAPE_DEBUG_INFO Borislav Petkov
@ 2008-01-27 19:45 ` Bartlomiej Zolnierkiewicz
2008-01-28 5:43 ` Borislav Petkov
2008-01-28 15:54 ` Bartlomiej Zolnierkiewicz
5 siblings, 2 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-27 19:45 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, linux-ide
Hi,
On Sunday 27 January 2008, Borislav Petkov wrote:
> Hi Bart,
>
> after a lot of hammering ide-tape got pimped pretty considerably (ca. 600 lines
> shorter and slicker :)). I'm sure there's more to be done like, e.g. replacing
Good work. :)
> the BKL in idetape_write_release() with finer-grained locking etc, probably also
> some pipeline improvements, removal of OnStream support, etc. but that'll come
> later.
On-Stream support has been long gone but it seems that deprecation
warning etc. managed to survive.
w.r.t. to the pipeline-mode: it should be pipelined into /dev/null
rationale:
- it is _very_ complex
- causes errors to be deferred till the next user-space access
- direct I/O using blk_rq_map_user() will offer superior performance
the only question is whether to remove it...
> Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++
> drivers/ide/Kconfig | 3 +-
> drivers/ide/ide-tape.c | 4146 +++++++++---------------
> 3 files changed, 1991 insertions(+), 2563 deletions(-)
applied #1-6, #8-9, #11-20, #29, #31
#10, #24 and #25 are also fine but since they depend on other patches
I couldn't merge them immediately
#7 and #21 need some recasting
#22 should be deferred for now
#26-28, #30 and #32 are still to be reviewed
BTW what happend to patch #23?
Thanks,
Bart
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/32] ide-tape redux v1
2008-01-27 19:45 ` [PATCH 0/32] ide-tape redux v1 Bartlomiej Zolnierkiewicz
@ 2008-01-28 5:43 ` Borislav Petkov
2008-01-30 0:29 ` Bartlomiej Zolnierkiewicz
2008-01-28 15:54 ` Bartlomiej Zolnierkiewicz
1 sibling, 1 reply; 14+ messages in thread
From: Borislav Petkov @ 2008-01-28 5:43 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel, linux-ide
Hi Bart,
[...]
> > the BKL in idetape_write_release() with finer-grained locking etc, probably also
> > some pipeline improvements, removal of OnStream support, etc. but that'll come
> > later.
>
> On-Stream support has been long gone but it seems that deprecation
> warning etc. managed to survive.
>
> w.r.t. to the pipeline-mode: it should be pipelined into /dev/null
>
> rationale:
> - it is _very_ complex
> - causes errors to be deferred till the next user-space access
> - direct I/O using blk_rq_map_user() will offer superior performance
>
> the only question is whether to remove it...
Well, on the one hand, since the driver is only being maintained we should not
remove code that works. Also, i don't know how many users ide-tape really has
but, would it be worth the trouble at all? Because if nobody's using it, we
could just as well pipe the whole thing into /dev/null.. On the other hand, the
pipelining part _is_ kinda big and, right, it is not that straightfoward to
look at it and know what it actually does - it truly is a student project :)
> > Documentation/ide/ChangeLog.ide-tape.1995-2002 | 405 +++
> > drivers/ide/Kconfig | 3 +-
> > drivers/ide/ide-tape.c | 4146 +++++++++---------------
> > 3 files changed, 1991 insertions(+), 2563 deletions(-)
[...]
> BTW what happend to patch #23?
Well, it appeared in my lkml mailbox having gone over vger which means at least
somebody got it :). But, yeah, that was a real nightmare yesterday sending all
those patches in one go. See, i got a stupid umts modem behind a not so transparent
proxy :) whose subnet is listed in almost every spam database on the planet
and whenever i try to send more than one mail i hit all sorts of mail server
restrictions like yahoo's maximum messages per day crap.. Gmail seems a bit
smarter ?! and scans the mail message and then says all kinds of funny stuff :):
27 10:48:31 gollum postfix/smtp[4011]: F1710123BFD: to=<linux-ide@vger.kernel.org>, relay=vger.kernel.org[209.132.176.167]:25,
delay=10, delays=0.19/0.29/2.7/7.2, dsn=2.7.1, status=sent (250 2.7.1 Looks like Linux source DIFF email.. BF:<H 1.55041e-06>; S1753942AbYA0Js4)
what's next, probably something like:
...(250 3.x.x uh, ok, i'm gonna relay your mail but please have another coffee, please) <hash>;
Anyway, resending #23 to you in a private mail.
--
Regards/Gruß,
Boris.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/32] ide-tape redux v1
2008-01-27 19:45 ` [PATCH 0/32] ide-tape redux v1 Bartlomiej Zolnierkiewicz
2008-01-28 5:43 ` Borislav Petkov
@ 2008-01-28 15:54 ` Bartlomiej Zolnierkiewicz
1 sibling, 0 replies; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-28 15:54 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, linux-ide
On Sunday 27 January 2008, Bartlomiej Zolnierkiewicz wrote:
> BTW what happend to patch #23?
my bad, the patch got eaten by gmail's spam filter...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/32] ide-tape redux v1
2008-01-28 5:43 ` Borislav Petkov
@ 2008-01-30 0:29 ` Bartlomiej Zolnierkiewicz
2008-02-01 8:21 ` Borislav Petkov
0 siblings, 1 reply; 14+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-01-30 0:29 UTC (permalink / raw)
To: petkovbb; +Cc: linux-kernel, linux-ide
On Monday 28 January 2008, Borislav Petkov wrote:
> Hi Bart,
>
> [...]
>
> > > the BKL in idetape_write_release() with finer-grained locking etc, probably also
> > > some pipeline improvements, removal of OnStream support, etc. but that'll come
> > > later.
> >
> > On-Stream support has been long gone but it seems that deprecation
> > warning etc. managed to survive.
> >
> > w.r.t. to the pipeline-mode: it should be pipelined into /dev/null
> >
> > rationale:
> > - it is _very_ complex
> > - causes errors to be deferred till the next user-space access
> > - direct I/O using blk_rq_map_user() will offer superior performance
> >
> > the only question is whether to remove it...
>
> Well, on the one hand, since the driver is only being maintained we should not
> remove code that works. Also, i don't know how many users ide-tape really has
> but, would it be worth the trouble at all? Because if nobody's using it, we
> could just as well pipe the whole thing into /dev/null.. On the other hand, the
This may be the other alternative... [ there is always libata PATA... ]
If you want to give ide-tape removal a try, go ahead (I suggest starting
with adding warning printk() and keeping patch in -mm for some time)...
> pipelining part _is_ kinda big and, right, it is not that straightfoward to
> look at it and know what it actually does - it truly is a student project :)
I have pipelining code figured out to some degree but reworking it is a rather
low-prio on my TODO list...
[...]
> Anyway, resending #23 to you in a private mail.
Thanks.
Bart
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/32] ide-tape redux v1
2008-01-30 0:29 ` Bartlomiej Zolnierkiewicz
@ 2008-02-01 8:21 ` Borislav Petkov
0 siblings, 0 replies; 14+ messages in thread
From: Borislav Petkov @ 2008-02-01 8:21 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel, linux-ide
On Wed, Jan 30, 2008 at 01:29:55AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Monday 28 January 2008, Borislav Petkov wrote:
> > Hi Bart,
> >
> > [...]
> >
> > > > the BKL in idetape_write_release() with finer-grained locking etc, probably also
> > > > some pipeline improvements, removal of OnStream support, etc. but that'll come
> > > > later.
> > >
> > > On-Stream support has been long gone but it seems that deprecation
> > > warning etc. managed to survive.
> > >
> > > w.r.t. to the pipeline-mode: it should be pipelined into /dev/null
> > >
> > > rationale:
> > > - it is _very_ complex
> > > - causes errors to be deferred till the next user-space access
> > > - direct I/O using blk_rq_map_user() will offer superior performance
> > >
> > > the only question is whether to remove it...
> >
> > Well, on the one hand, since the driver is only being maintained we should not
> > remove code that works. Also, i don't know how many users ide-tape really has
> > but, would it be worth the trouble at all? Because if nobody's using it, we
> > could just as well pipe the whole thing into /dev/null.. On the other hand, the
>
> This may be the other alternative... [ there is always libata PATA... ]
>
> If you want to give ide-tape removal a try, go ahead (I suggest starting
> with adding warning printk() and keeping patch in -mm for some time)...
Well, we don't have any numbers on whether someone is using the driver at all,
so i probably the best thing we should do is give it a grace period of 1/2 year
before we get rid of it. In the meantime, let's see how many souls cry out :)
---
commit 5b4566d1ed9b050d53d776285da84f8c3cc13d2c
Author: Borislav Petkov <petkovbb@gmail.com>
Date: Fri Feb 1 09:12:02 2008 +0100
ide-tape: schedule driver for removal after 6 months in case it doesn't have
any users left.
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 20c4c8b..21d71a9 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,13 @@ Why: This driver has been marked obsolete for many years.
Who: Stephen Hemminger <shemminger@linux-foundation.org>
---------------------------
+
+What: ide-tape driver
+When: July 2008
+Files: drivers/ide/ide-tape.c
+Why: This driver might not have any users anymore and maintaining it for no
+ reason is an effort no one wants to make.
+Who: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov
+ <petkovbb@googlemail.com>
+
+---------------------------
diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index f51712c..fd81f4c 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -3829,6 +3829,11 @@ static int ide_tape_probe(ide_drive_t *drive)
g->fops = &idetape_block_ops;
ide_register_region(g);
+ printk(KERN_WARNING "It is possible that this driver does not have any"
+ " users anymore and, as a result, it will be REMOVED soon."
+ " Please notify Bart <bzolnier@gmail.com> or Boris"
+ " <petkovbb@gmail.com> in case you still need it.\n");
+
return 0;
out_free_tape:
--
Regards/Gruß,
Boris.
^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-02-01 8:22 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-27 8:41 [PATCH 0/32] ide-tape redux v1 Borislav Petkov
2008-01-27 8:41 ` [PATCH 1/32] ide-tape: move historical changelog to Documentation/ide/ChangeLog.ide-tape.1995-2002 Borislav Petkov
2008-01-27 15:18 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 2/32] ide-tape: remove dead code Borislav Petkov
2008-01-27 8:41 ` [PATCH 3/32] ide-tape: remove struct idetape_request_sense_result_t Borislav Petkov
2008-01-27 15:19 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 4/32] ide-tape: remove struct idetape_mode_parameter_header_t Borislav Petkov
2008-01-27 15:25 ` Bartlomiej Zolnierkiewicz
2008-01-27 8:41 ` [PATCH 5/32] ide-tape: remove IDETAPE_DEBUG_INFO Borislav Petkov
2008-01-27 19:45 ` [PATCH 0/32] ide-tape redux v1 Bartlomiej Zolnierkiewicz
2008-01-28 5:43 ` Borislav Petkov
2008-01-30 0:29 ` Bartlomiej Zolnierkiewicz
2008-02-01 8:21 ` Borislav Petkov
2008-01-28 15:54 ` Bartlomiej Zolnierkiewicz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).