summaryrefslogtreecommitdiffstats
path: root/include/linux/mtio.h
Commit message (Collapse)AuthorAgeFilesLines
* compat_ioctl: move tape handling into driversArnd Bergmann2019-10-231-0/+60
| | | | | | | | | | | | | | | | | | | | | | MTIOCPOS and MTIOCGET are incompatible between 32-bit and 64-bit user space, and traditionally have been translated in fs/compat_ioctl.c. To get rid of that translation handler, move a corresponding implementation into each of the four drivers implementing those commands. The interesting part of that is now in a new linux/mtio.h header that wraps the existing uapi/linux/mtio.h header and provides an abstraction to let drivers handle both cases easily. Using an in_compat_syscall() check, the caller does not have to keep track of whether this was called through .unlocked_ioctl() or .compat_ioctl(). Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "Kai Mäkisara" <Kai.Makisara@kolumbus.fi> Cc: linux-scsi@vger.kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* UAPI: (Scripted) Disintegrate include/linuxDavid Howells2012-10-131-208/+0
| | | | | | | | | Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* [SCSI] st: expand ability to write immediate filemarksLee Duncan2012-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The st tape driver recently added the MTWEOFI ioctl, which writes a tape filemark (EOF), like the MTWEOF ioctl, except that MTWEOFI returns immediately. This makes certain applications, like backup software, run much more quickly on buffered tape drives. Since legacy applications do not know about this new MTWEOFI ioctl, this patch adds a new ioctl option that tells the st driver to return immediately when writing an EOF (i.e. a filemark). This new flag is much like the existing flag that tells the st driver to perform writes (and certain other IOs) immediately, but this new flag only applies to writing EOFs. This new feature is controlled via the MTSETDRVBUFFER ioctl, using the newly-defined MT_ST_NOWAIT_EOF flag. Use of this new feature is displayed via the sysfs tape "options" attribute. The st documentation was updated to mention this new flag, as well as the problems that can occur from using it. Signed-off-by: Lee Duncan <lduncan@suse.com> Acked-by: Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* [SCSI] st: add MTWEOFI to write filemarks without flushing drive bufferKai Makisara2010-10-081-0/+1
| | | | | | | | | | This patch adds a new MTIOCTOP operation MTWEOFI that writes filemarks with immediate bit set. This means that the drive does not flush its buffer and the next file can be started immediately. This speeds up writing in applications that have to write multiple small files. Signed-off-by: Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
* [SCSI] st: add option to use SILI in variable block readsKai Makisara2008-04-071-0/+1
| | | | | | | | | | | Add new option MT_ST_SILI to enable setting the SILI bit in reads in variable block mode. If SILI is set, reading a block shorter than the byte count does not result in CHECK CONDITION. The length of the block is determined using the residual count from the HBA. Avoiding the REQUEST SENSE command for every block speeds up some real applications considerably. Signed-off-by: Kai Makisara <kai.makisara@kolumbus.fi> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* more ftape removalAdrian Bunk2007-01-231-146/+0
| | | | | | | This patch removes some more ftape code. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+351
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!