| Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
into suse.de:/home/greg/linux/BK/usb-2.6
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
|
|
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>
|
|
|
|
Signed-off-by: Marcus Meissner <meissner@suse.de>
Added missing DM_REMOVE_ALL call.
|
|
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
|
|
|
|
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.
|
|
|
|
From: Marcel Holtmann <marcel@holtmann.org>
This patch adds the needed compat ioctl's for the CAPI on 64bit platforms.
|
|
From: Kevin Corry <kevcorry@us.ibm.com>
Fix 64/32 bit ioctl problems.
|
|
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.
|
|
into nuts.davemloft.net:/disk1/BK/net-2.6
|
|
This patch adds the missing compat ioctl's for the CAPI Message Transport
Protocol.
|
|
|
|
From: Joe Thornber <thornber@redhat.com>
List targets ioctl. [Patrick Caulfield]
|
|
From: Joe Thornber <thornber@redhat.com>
Remove the version-1 ioctl interface.
|
|
Thanks to Eric Brower for spotting this.
|
|
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
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
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]
|
|
The compat ioctls for device mapper were not being enabled due to an
incorrect config option.
|
|
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
|
|
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.
|
|
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.
|
|
CONFIG_BLK_DEV_LVM is gone, but there is still some associated code.
This is the include/linux/compat_ioctl.h part.
|