similar to: [PATCH 00/25] reduce code in fs/compat_ioctl.c

Hi Jens, James and Martin, This series concludes the work I did for linux-5.5 on the compat_ioctl() cleanup, killing off fs/compat_ioctl.c and block/compat_ioctl.c by moving everything into drivers. Overall this would be a reduction both in complexity and line count, but as I'm also adding documentation the overall number of lines increases in the end. My plan was originally to keep the

Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() handler that implements the same commands by calling scsi_compat_ioctl(). The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible at this point, so any driver that calls those can do so for both native and compat mode, with the argument passed through compat_ptr(). With this, we can remove the entries from

Al, Could this be included in the vfs queue? This patch adds ioctls to vfs for compatibility with legacy XFS pre-allocation ioctls (XFS_IOC_*RESVP*). The implementation effectively invokes sys_fallocate for the new ioctls. Also handles the compat_ioctl case. Note: These legacy ioctls are also implemented by OCFS2. Signed-off-by: Ankit Jain <me at ankitjain.org> Reviewed-by: Christoph

Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() handler that implements the same commands by calling scsi_compat_ioctl(). The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible at this point, so any driver that calls those can do so for both native and compat mode, with the argument passed through compat_ptr(). With this, we can remove the entries from

Hi Andreas, I need the following patch to make ext3 online resizing work with linux 2.6.11.6 on amd64 with a 32bit userland. Do the changes look o.k.? I converted everything to ext3 since it should implement the calls for ext2 in a compatible way and we only have to include ext3 headers then. The COMPATIBLE_IOCTL() should probably into compat_ioctl.h, I'll send an updated version in case

changeset: 30726:2a6fda4e7dde1a0a5d29a62303e85bcea868eb47 tag: tip user: Jimi Xenidis <jimix@watson.ibm.com> date: Thu Jul 13 11:51:38 2006 -0400 files: drivers/xen/privcmd/Makefile drivers/xen/privcmd/compat_privcmd.c fs/compat_ioctl.c include/xen/public/privcmd.h description: [ppc] ioctl32() compat plumbing for xen calls The following patch deals with xen

On Wed, Dec 11, 2019 at 09:42:49PM +0100, Arnd Bergmann wrote: > Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() > handler that implements the same commands by calling scsi_compat_ioctl(). > > The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible > at this point, so any driver that calls those can do so for both native > and compat mode, with

On Wed, Dec 11, 2019 at 09:42:49PM +0100, Arnd Bergmann wrote: > Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() > handler that implements the same commands by calling scsi_compat_ioctl(). > > The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible > at this point, so any driver that calls those can do so for both native > and compat mode, with

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com>

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com>

On Tue, Apr 16, 2019 at 10:19:47PM +0200, Arnd Bergmann wrote: > Each of these drivers has a copy of the same trivial helper function to > convert the pointer argument and then call the native ioctl handler. > > We now have a generic implementation of that, so use it. > > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > Reviewed-by: Jarkko Sakkinen

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Signed-off-by: Arnd Bergmann <arnd at arndb.de> --- drivers/char/ppdev.c | 12 +--------- drivers/char/tpm/tpm_vtpm_proxy.c | 12 +--------- drivers/firewire/core-cdev.c | 12

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Acked-by: Michael S. Tsirkin <mst at redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com>

On Wed, Sep 12, 2018 at 5:33 PM Jason Gunthorpe <jgg at ziepe.ca> wrote: > > On Wed, Sep 12, 2018 at 05:01:03PM +0200, Arnd Bergmann wrote: > > Each of these drivers has a copy of the same trivial helper function to > > convert the pointer argument and then call the native ioctl handler. > > > > We now have a generic implementation of that, so use it. > >

On 12/12/19 00:05, Michael S. Tsirkin wrote: >> @@ -405,6 +405,9 @@ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo) >> >> static const struct block_device_operations virtblk_fops = { >> .ioctl = virtblk_ioctl, >> +#ifdef CONFIG_COMPAT >> + .compat_ioctl = blkdev_compat_ptr_ioctl, >> +#endif >> .owner =

On Wed, Feb 12, 2020 at 10:15 PM Johannes Hirte <johannes.hirte at datenkhaos.de> wrote: > > On 2020 Jan 02, Arnd Bergmann wrote: > > Error in getting drive hardware properties > Error in getting drive reading properties > Error in getting drive writing properties > __________________________________ > > Disc mode is listed as: CD-DA > ++ WARN: error in ioctl

On Thu, Dec 12, 2019 at 01:28:08AM +0100, Paolo Bonzini wrote: > I think it's because the only ioctl for virtio-blk is SG_IO. It makes > sense to lump it in with scsi, but I wouldn't mind getting rid of > CONFIG_VIRTIO_BLK_SCSI altogether. CONFIG_VIRTIO_BLK_SCSI has been broken for about two years, as it never set the QUEUE_FLAG_SCSI_PASSTHROUGH flag after that was introduced.

Hi, > static const struct file_operations bochs_fops = { > .owner = THIS_MODULE, > - .open = drm_open, > - .release = drm_release, > - .unlocked_ioctl = drm_ioctl, > - .compat_ioctl = drm_compat_ioctl, > - .poll = drm_poll, > - .read = drm_read, > .llseek = no_llseek, > - .mmap = bochs_mmap, > + DRM_VRAM_MM_FILE_OPERATIONS > }; What about

Given the need for 4K doorbell such that QEMU can easily map, ect, and assuming that I have a HW device which exposes 2 VQ's, with a notification area off of BAR3, offset=whatever, notifier_multiplier=4, we don't need to have 2 x 4K pages mapped into the VM for both doorbells do we? The guest driver would ring DB0 at BAR4+offset, and DB1 at BAR4+offset+(4*1). The 4K per DB is useful how?

Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_gem_vram_helper.h | 18 ---- include/drm/drm_vram_mm_helper.h | 82 +++++++++++++++++++ drivers/gpu/drm/ast/ast_drv.c | 5 +- drivers/gpu/drm/bochs/bochs_drv.c