summaryrefslogtreecommitdiff
path: root/include/linux/compat_ioctl.h
AgeCommit message (Collapse)Author
2006-03-09[PATCH] mtd: 64 bit fixesAtsushi Nemoto
Fix some bugs in mtd/jffs2 on 64bit platform. The MEMGETBADBLOCK/MEMSETBADBLOCK ioctl are not listed in compat_ioctl.h. And some variables in jffs2 are declared as uint32_t but used to hold size_t values. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10[PATCH] sanitize building of fs/compat_ioctl.cChristoph Hellwig
Now that all these entries in the arch ioctl32.c files are gone [1], we can build fs/compat_ioctl.c as a normal object and kill tons of cruft. We need a special do_ioctl32_pointer handler for s390 so the compat_ptr call is done. This is not needed but harmless on all other architectures. Also remove some superflous includes in fs/compat_ioctl.c Tested on ppc64. [1] parisc still had it's PPP handler left, which is not fully correct for ppp and besides that ppp uses the generic SIOCPRIV ioctl so it'd kick in for all netdevice users. We can introduce a proper handler in one of the next patch series by adding a compat_ioctl method to struct net_device but for now let's just kill it - parisc doesn't compile in mainline anyway and I don't want this to block this patchset. Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Matthew Wilcox <willy@debian.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-09V4L (926_2): Moves compat32 functions from fs to v4l subsystemArnd Bergmann
This moves the 32 bit ioctl compatibility handlers for Video4Linux into a new file and adds explicit calls to them to each v4l device driver. Unfortunately, there does not seem to be any code handling the v4l2 ioctls, so quite often the code goes through two separate conversions, first from 32 bit v4l to 64 bit v4l, and from there to 64 bit v4l2. My patch does not change that, so there is still much room for improvement. Also, some drivers have additional ioctl numbers, for which the conversion should be handled internally to that driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
2005-11-16[DVB]: Add compat ioctl handling.David S. Miller
Based upon a patch by Guido Guenther <agx@sigxcpu.org>. Some of these ioctls had embedded time_t objects or pointers, so needed translation. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-12[SPARC]: Fix RTC compat ioctl kernel log spam.Christoph Hellwig
On Fri, Nov 11, 2005 at 12:58:40PM -0800, David S. Miller wrote: > > This change: > > diff-tree 8ca2bdc7a98b9584ac5f640761501405154171c7 (from feee207e44d3643d19e648aAuthor: Christoph Hellwig <hch@lst.de> > Date: Wed Nov 9 12:07:18 2005 -0800 > > [SPARC] sbus rtc: implement ->compat_ioctl > > Signed-off-by: Christoph Hellwig <hch@lst.de> > Signed-off-by: David S. Miller <davem@davemloft.net> > > results in the console now getting spewed on sparc64 systems > with messages like: > > [ 11.968298] ioctl32(hwclock:464): Unknown cmd fd(3) cmd(401c7014){00} arg(efc > What's happening is hwclock tries first the SBUS rtc device ioctls > then the normal rtc driver ones. > > So things actually worked better when we had the SBUS rtc compat ioctl > directly handled via the generic compat ioctl code. > > There are _so_ many rtc drivers in the kernel implementing the > generic rtc ioctls that I don't think putting a ->compat_ioctl > into all of them to fix this problem is feasible. Unless we > write a single rtc_compat_ioctl(), export it to modules, and hook > it into all of those somehow. > > But even that doesn't appear to have any pretty implementation. > > Any better ideas? We had similar problems with other ioctls where userspace did things like that. What we did there was to put the compat handler to generic code. The patch below does that, adding a big comment about what's going on and removing the COMPAT_IOCTL entires for these on powerpc that not only weren't ever useful but are duplicated now aswell. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-09[PATCH] fbdev: move ioctl32 code to fbmem.cArnd Bergmann
The frame buffer layer already had some code dealing with compat ioctls, this patch moves over the remaining code from fs/compat_ioctl.c Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-09[PATCH] move some COMPATIBLE_IOCTL entries from x86_64 to common codeChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-04[SPARC64/COMPAT]: Add some compat ioctl for ppdevRaphael Assenat
The following patch adds some ioctls to include/linux/compat_ioctl.h to allow using ppdev from the 32 bit user space on sparc64. This patch also adds the PPDEV option in the sparc64 menu, near Parallel printer support in the 'General machine setup' submenu. All those ioctls seem to be compatible, since (correct me if I'm wrong) they dont use the 'long' type. See include/linux/ppdev.h. The application I used to test the new ioctls only used the following: PPEXCL PPCLAIM PPNEGOT PPGETMODES PPRCONTROL PPWCONTROL PPDATADIR PPWDATA PPRDATA But I beleive that the other ioctls will work fine. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-03-08Merge suse.de:/home/greg/linux/BK/bleed-2.6Greg Kroah-Hartman
into suse.de:/home/greg/linux/BK/usb-2.6
2005-03-07[PATCH] add TCSBRKP to compat_ioctl.hArun Sharma
Move ioctl TCSBRKP support to compat layer. Same rationale as TCSBRK. - Remove corresponding code under ppc64, sparc64 and s390. - Use ULONG_IOCTL() instead of COMPATIBLE_IOCTL(), since the argument is int, not pointer. Signed-off-by: Gordon Jin <gordon.jin@intel.com> Signed-off-by: Arun Sharma <arun.sharma@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-03-07[PATCH] USB: compat ioctl for submiting URBAndrew Morton
From: Christopher Li <chrisl@vmware.com> - Let usbdevfs directly handle 32 bit URB ioctl. More specifically: USBDEVFS_SUBMITURB32, USBDEVFS_REAPURB32 and USBDEVFS_REAPURBNDELAY32. Those asynchronous ioctls are too complicate to handle by the compatible layer. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-01-20[PATCH] ioctl compatibility for TIOCMIWAIT and TIOCGICOUNTPaul Mackerras
This patch lets us use TIOCMIWAIT and TIOCGICOUNT from a 32-bit process on a 64-bit processor. TIOCMIWAIT uses the argument as a bitmap of things to wait for. The argument for TIOCGICOUNT points to a struct serial_icounter_struct, which only contains ints and arrays of int. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-11-15[PATCH] device-mapper: Add DM_TARGET_MSGAlasdair G. Kergon
Add DM_TARGET_MSG ioctl so data can be passed to a dm target after its table has been loaded. Signed-Off-By: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-11-07[PATCH] Add argument-less ppdev ioctls to compat_ioctl.hPetr Vandrovec
ppdev's ioctls are not available for 32bit apps on 64bit systems. There are four ioctls which take no argument at all (so they are compatible between 32bit and 64bit), these numbers do not clash with any other ioctl code, and so I see no reason why not applying patch below. It solves problem VMware users are faced on 64bit systems if they want to use direct access to the parallel port. Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-10-20[PATCH] x86_64: no TIOCSBRK/TIOCCBRK in ia32 emulationWerner Almesberger
In ia32 emulation, the amd64 kernel refuses the ioctls TIOCSBRK and TIOCCBRK with EINVAL. I've attached a patch that adds them to the compatibility list. Since all architectures have these ioctls ("m68knommu" inherits them from "m68k", "um" from its host) and use the same code, I think adding them to compat_ioctl.h is the correct choice (as opposed to adding them to arch/x86_64/ia32/ia32_ioctl.c). Signed-off-by: Werner Almesberger <werner@almesberger.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-10-18[PATCH] CDRW packet writing supportPeter Osterlund
This patch implements CDRW packet writing as a kernel block device. Usage instructions are in the packet-writing.txt file. A hint: If you don't want to wait for a complete disc format, you can format just a part of the disc. For example: cdrwtool -d /dev/hdc -m 10240 This will format 10240 blocks, ie 20MB. Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-08-25Manual merge.Vojtech Pavlik
Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
2004-08-22[PATCH] mark LOOP_CHANGE_FD as an ULONG compat ioctlArjan van de Ven
LOOP_CHANGE_FD is an ULONG compatible ioctl, basically same calling convention as LOOP_SET_FD; mark it as such in the compat ioctl list. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-08-20[WATCHDOG] v2.6.8.1 compat_ioctl-patchArnd Bergmann
The watchdog ioctl interface is defined correctly for 32 bit emulation, although WIOC_GETSUPPORT was not marked as such, for an unclear reason. WDIOC_SETTIMEOUT and WDIOC_GETTIMEOUT were added in may 2002 to the code but never to the ioctl list. This adds all three definitions. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2004-07-07Merge suse.cz:/data/bk/linus into suse.cz:/data/bk/inputVojtech Pavlik
2004-07-04[Bluetooth] Add HID protocol supportMarcel Holtmann
This patch adds support for the Bluetooth HID protocol to the Bluetooth subsystem. Currently only the boot mode is supported. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2004-06-05Merge suse.cz:/home/vojtech/bk/linus into suse.cz:/home/vojtech/bk/inputVojtech Pavlik
2004-06-02[PATCH] dm: add DM_REMOVE_ALL_32 compat ioctlAndrew Morton
From: Marcus Meissner <meissner@suse.de> Add DM_REMOVE_ALL_32 to the list of compatible ioctls. Signed-off-By: Marcus Meissner <meissner@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2004-05-29Merge suse.cz:/home/vojtech/bk/linus into suse.cz:/home/vojtech/bk/inputVojtech Pavlik
2004-05-24[PATCH] missing compat ioctl mapping for DM_REMOVE_ALLAndrew Morton
Signed-off-by: Marcus Meissner <meissner@suse.de> Added missing DM_REMOVE_ALL call.
2004-05-21[BRIDGE]: Compat hooks for new-ioctl interface.Stephen Hemminger
Replacement 64 bit compatibility code for the new ioctl's. The new ioctl's all pass through clean, but for the old style ioctl's it uses the mis-feature of the earlier bridge-utils that they check the API version. So if an old 32bit version of brctl is run on a 64bit platform it will report bridge utilities not compatible with kernel version Tested on Itanium 1; but should solve issue for sparc, ppc, and x86_64
2004-05-19input: Add 64-bit compatible ioctls for hiddev.Adam Kropelin
2004-05-14[PATCH] autofs4 compat ioctlsAndrew Morton
From: <raven@themaw.net> These are the ioctls that need to be added to the compatibility layer. They are all esentially the same as the AUTOFS_IOC_PROTOVER in their requirements and so should be fine.
2004-04-26[COMPAT]: HDIO_DRIVE_TASK is a compatible ioctl.Eric Brower
2004-04-20[PATCH] i4l: add compat ioctl's for CAPIAndrew Morton
From: Marcel Holtmann <marcel@holtmann.org> This patch adds the needed compat ioctl's for the CAPI on 64bit platforms.
2004-04-17[PATCH] dm: Fix 64/32 bit ioctl problems.Andrew Morton
From: Kevin Corry <kevcorry@us.ibm.com> Fix 64/32 bit ioctl problems.
2004-03-26[PATCH] Emulate deviceless bridge ioctlsAndi Kleen
This helps vmware users running vmware on x86-64 - vmnet tries to set up a bridge. Emulate these ioctls. The bridge has more ioctls on its bridge device, but these don't seem to be needed here.
2004-03-21Merge http://linux-mh.bkbits.net/bluetooth-2.6David S. Miller
into nuts.davemloft.net:/disk1/BK/net-2.6
2004-03-20[Bluetooth] Add missing compat ioctl's for CMTPMarcel Holtmann
This patch adds the missing compat ioctl's for the CAPI Message Transport Protocol.
2004-03-19Add FBIOBLANK to list of compatible ioctls.Linus Torvalds
2004-03-11[PATCH] dm: list targets cmdAndrew Morton
From: Joe Thornber <thornber@redhat.com> List targets ioctl. [Patrick Caulfield]
2004-03-06[PATCH] dm: remove v1 ioctl interfaceAndrew Morton
From: Joe Thornber <thornber@redhat.com> Remove the version-1 ioctl interface.
2004-02-01[COMPAT]: Fix TUNSETIFF ioctl compat, it takes an ifreq ptr not an int.David S. Miller
Thanks to Eric Brower for spotting this.
2004-01-18[PATCH] s390: 32 bit ioctl emulation fixes.Andrew Morton
From: Martin Schwidefsky <schwidefsky@de.ibm.com> - audit all 32 bit pointer accesses and make them use compat_ioctl(), because of the necessary conversion on s390 - introduce ULONG_IOCTL() which is used instead of COMPATIBLE_IOCTL() for all ioctls that have their argument encoded in 'arg' instead of the memory pointed to by arg. Same reason as above. - remove most #ifdefs in <linux/compat_ioctl.h>: They don't make any sense if the respective handlers in fs/compat_ioctl.c are not disabled as well and they are potentially harmful (the CONFIG_BLK_DEV_DM e.g. was insufficient). - comment out COMPATIBLE_IOCTL(SIOCSIFBR) and COMPATIBLE_IOCTL(SIOCGIFBR), they appear to require a handler - implement copy_in_user for s390, as needed for many handlers in fs/compat_ioctl.c - get rid of all duplicate stuff in arch/s390/kernel/compat_ioctl.c that is also in fs/compat_ioctl.c
2004-01-12[COMPAT]: Support wireless ioctls, with help from Clint Adams.David S. Miller
2004-01-12[COMPAT]: Mark SIOCSIFNAME as compatible ioctl.Andi Kleen
2003-12-29[PATCH] compat_ioctl for i2cAndrew Morton
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> I needed those for the G5 on ppc64, so here they are, I was only able to test the SMBUS stuff though.
2003-10-01[PATCH] Disable floppy and the related ioctl32s on some platformsAndrew Morton
From: Arun Sharma <arun.sharma@intel.com> Based on some earlier discussion: http://marc.theaimsgroup.com/?t=106015010700002&r=1&w=2 here's a new patch that attempts to disable BLK_DEV_FD on platforms which don't support it. The patch also attempts to remove the duplication of the logic in compat_ioctl.h.
2003-09-26Remove killed SCSI_IOCTL_TAGGED_{ENABLE|DISABLE} from compat_ioctl.hJames Bottomley
2003-08-06[PATCH] dm: 64 bit ioctl fixesAndrew Morton
From: Joe Thornber <thornber@sistina.com> Update the ioctl32 handlers for the 64-bit architectures to recognize the new Device-Mapper version 4 ioctls. The version 1 ioctls are still there. If/When the version 1 ioctls are removed, these same files will need to be updated again. I have been unable to test this patch yet, since I have not had any luck getting 2.6.0-test2 to compile on my ppc64 box (not a dm-related problem). But the patch is pretty trivial, so I'm pretty confident it will work. If anyone else can test this (on mips64, sparc64, parisc, or x86-64), let me know if you have any problems. [Kevin Corry]
2003-07-05[PATCH] enable device mapper in compat layerAnton Blanchard
The compat ioctls for device mapper were not being enabled due to an incorrect config option.
2003-06-14[PATCH] compat_ioctl fixesAndrew Morton
From: Anton Blanchard <anton@samba.org> - Add BLKRASET/BLKFRASET as compatible ioctls - Remove ifdefs around RTC ioctls - ppc64 implements its own rtc driver and doesnt define CONFIG_RTC. - remove SG_IO which is not compatible - extra loop, autofs, NCP and bluetooth ioctls
2003-06-10[PATCH] Remove DRM ioctls for common compat ioctl codeAndrew Morton
From: Andi Kleen <ak@suse.de> This makes the 2.5 kernel with common ioctl32 code compile with DRM enabled again. The DRM code in the kernel is obsolete anyways and has been long removed. It definitely does not belong in the common ioctl emulation layer. Egbert Eich is working on proper 32bit DRM emulation, but it will be likely directly integrated in the DRI/DRM sources.
2003-06-07[PATCH] common 32-bit ioctl codeAndrew Morton
From: Pavel Machek <pavel@suse.cz> Various 64-bit architectures are duplicating a ton of 32-bit compat code. Pavel's patch creates a generic 32-bit ioctl file in fs/compat_ioctl.c which architectures will #include from within their arch/ layer. Has been reviewed by everyone and tested on sparc64, x86_64, ppc64 and ia32.
2003-05-26[PATCH] kill lvm from compat_ioctl.hAndries E. Brouwer
CONFIG_BLK_DEV_LVM is gone, but there is still some associated code. This is the include/linux/compat_ioctl.h part.