All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: akpm@osdl.org, schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] ->compat_ioctl for 390 tape_char
Date: Sat, 5 Nov 2005 02:16:56 +0100	[thread overview]
Message-ID: <200511050217.02547.arnd@arndb.de> (raw)
In-Reply-To: <20051104235148.GA10604@lst.de>

On Sünnavend 05 November 2005 00:51, Christoph Hellwig wrote:
> we return -ENOIOCTLCMD if we didn't have a valid compat ioctl, and in
> that case the vfs code will try to find it in the core translation
> table.

No, the function you wrote returns -ENOIOCTLCMD only if
device->discipline->ioctl_fn is NULL, otherwise it returns the
code it gets from that function, which is -EINVAL.

> I'm not sure moving everything from fs/compat_ioctl.c is a good idea.
> Everything that is just in a single driver or subsystem that has
> common ioctl code - sure.  else it doesn't make a lot of sense.

It turns out that almost everything is a single driver, the exceptions
are:

- tty ioctls: I move the conversion into drivers/char/tty_io.c with a
  relatively big switch() statement. All drivers implementing these
  use tty_operations.
- block ioctl: similar for drivers/block/ioctl.c
- net ioctl: similar for net/compat.c. I also add compat_ioctl methods
  for proto_ops.
- cdrom, tape, v4l: I create a new file that contains a compat_ioctl
  file operation that can be used in each driver, either by pointing
  directly to it or by calling it from their own compat_ioctl
  handler. The handlers end up calling f_op->ioctl() internally.
- file systems: many file systems implement EXT2_IOC_GETFLAGS etc.
  those are trivial to handle, so I duplicate the code for each of those
  file systems.

	Arnd <><

  reply	other threads:[~2005-11-05  1:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-04 22:18 [PATCH 4/4] ->compat_ioctl for 390 tape_char Christoph Hellwig
2005-11-04 23:10 ` Arnd Bergmann
2005-11-04 23:51   ` Christoph Hellwig
2005-11-05  1:16     ` Arnd Bergmann [this message]
2005-11-07  4:01       ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200511050217.02547.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@osdl.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.