All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "David S. Miller" <davem@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org
Subject: Re: ioctl cleanups: enable sg_io and serial stuff to be shared
Date: Thu, 8 May 2003 22:33:14 +0200	[thread overview]
Message-ID: <20030508203313.GA2787@elf.ucw.cz> (raw)
In-Reply-To: <1052323484.9817.14.camel@rth.ninka.net>

Hi!

> > Not sure if we are not too close to stable release to do that? And I
> > see no incremental way how to get there. Moving compatibility stuff
> > closer to drivers can be done close to stable release...
> 
> You can define it as follows:
> 
> 1) If entry exists in COMPAT or TRANSLATE table, invoke
>    fops->ioctl(), else
> 
> 2) If ->compat_ioctl() exists, invoke that, else
> 
> 3) Fail.
> 
> The COMPAT tables are sort of valuable, in that it eliminates
> the need to duplicate code when all of a drivers ioctls need
> no translation.
> 
> BTW, need to extend this to netdev->do_ioctl as well for the
> handling of SIOCDEVPRIVATE based stuff.  Oh goody, we can finally
> fix up that crap :))))

There's a *lot* of structs that contain *ioctl:
pavel@amd:/usr/src/linux-test/include/linux$ grep "*ioctl" *
pavel@amd:/usr/src/linux-test/include/linux$ grep "*ioctl" *
atmdev.h:       int (*ioctl)(struct atm_dev *dev,unsigned int cmd,void *arg);
atmdev.h:       int (*ioctl)(struct atm_dev *dev,unsigned int cmd,void *arg);
fs.h:   int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long);
fs.h:   int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
hdlc.h: int (*ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd);
hdlcdrv.h:      int (*ioctl)(struct net_device *, struct ifreq *,
ide.h:  int             (*ioctl)(ide_drive_t *, struct inode *, struct file *, unsigned int, unsigned long);
if_bridge.h:extern void brioctl_set(int (*ioctl_hook)(unsigned long));
if_pppox.h:     int             (*ioctl)(struct socket *sock, unsigned int cmd,
ioctl32.h:typedef int (*ioctl_trans_handler_t)(unsigned int, unsigned int, unsigned long, struct file *);
loop.h: int             (*ioctl)(struct loop_device *, int cmd,
loop.h: int (*ioctl)(struct loop_device *, int cmd, unsigned long arg);
net.h:  int             (*ioctl)     (struct socket *sock, unsigned int cmd,
ppp_channel.h:  int     (*ioctl)(struct ppp_channel *, unsigned int, unsigned long);
serial_core.h:  int             (*ioctl)(struct uart_port *, unsigned int, unsigned long);
tty_driver.h: * int  (*ioctl)(struct tty_struct *tty, struct file * file,
tty_driver.h:   int  (*ioctl)(struct tty_struct *tty, struct file * file,
tty_ldisc.h: * int      (*ioctl)(struct tty_struct * tty, struct file * file,
tty_ldisc.h:    int     (*ioctl)(struct tty_struct * tty, struct file * file,
usb.h:  int (*ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
wanrouter.h:    int (*ioctl) (struct wan_device *wandev, unsigned cmd,
pavel@amd:/usr/src/linux-test/include/linux$

What about this one: redefine it to (*ioctl)( ...., unsigned *long*,
unsinged long). That means we can add 

#define IOCTL_COMPAT 0x1 0000 0000

and avoid adding new field to each such structure. Also I will not
have to duplicate lots of middle-level code (I will have to modify
unsigned int -> unsigned long, but no second copies of everything). It
means that architecture with CONFIG_COMPAT needs to have unsigned long
> 32 bits, but I guess we can live with that.

What do you think?
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

  parent reply	other threads:[~2003-05-08 20:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030507104008$12ba@gated-at.bofh.it>
2003-05-07 11:51 ` ioctl cleanups: enable sg_io and serial stuff to be shared Arnd Bergmann
2003-05-07 12:41   ` Pavel Machek
2003-05-07 12:56     ` Christoph Hellwig
2003-05-07 14:39       ` David S. Miller
2003-05-07 15:12         ` Jeff Garzik
2003-05-07 14:07           ` David S. Miller
2003-05-08 10:46         ` Gerd Knorr
2003-05-08 15:16         ` Ben Collins
2003-05-08 15:51           ` Christoph Hellwig
2003-05-08 15:37             ` Ben Collins
2003-05-08 19:34           ` Pavel Machek
2003-05-08 19:27             ` Ben Collins
2003-05-08 20:06               ` Pavel Machek
2003-05-08 19:47                 ` Ben Collins
2003-05-08 20:09                 ` David S. Miller
2003-05-08 20:26               ` David Mosberger
2003-05-08 20:33                 ` Arjan van de Ven
2003-05-08 21:11                   ` David Mosberger
2003-05-08 15:23         ` Arnd Bergmann
2003-05-07 15:28       ` Pavel Machek
2003-05-07 16:04         ` David S. Miller
2003-05-07 19:13           ` Arnd Bergmann
2003-05-07 18:12             ` David S. Miller
2003-05-07 23:50               ` Arnd Bergmann
2003-05-08 10:35                 ` David S. Miller
2003-05-07 22:20             ` Alan Cox
2003-05-08 20:33           ` Pavel Machek [this message]
2003-05-08 20:43             ` David S. Miller
2003-05-08 23:03               ` Pavel Machek
2003-05-08 23:35                 ` Arnd Bergmann
2003-05-08 22:48             ` Arnd Bergmann
2003-05-08 23:22               ` Pavel Machek
2003-05-07 13:18     ` Arnd Bergmann
2003-05-07 14:01       ` Carl-Daniel Hailfinger
2003-05-07 15:16       ` Pavel Machek
2003-05-07 15:46         ` Arnd Bergmann
2003-05-07 16:07           ` Jens Axboe
2003-05-07 16:20             ` Arnd Bergmann
2003-05-07 10:27 Pavel Machek

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=20030508203313.GA2787@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=arnd@arndb.de \
    --cc=davem@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.