LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Tomas Carnecky <tom@dbservice.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	ecki-news2004-05@lina.inka.de, linux-kernel@vger.kernel.org
Subject: Re: Problem with ioctl command TCGETS
Date: Sun, 28 Nov 2004 14:05:52 +0000
Message-ID: <20041128140552.GD26051@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <41A9D093.4090908@dbservice.com>

On Sun, Nov 28, 2004 at 02:20:19PM +0100, Tomas Carnecky wrote:
> But then you'd have to open another file :(

Correct, but not necessary on sysfs.

> And what about somethink like:
> cdrom_fd = open("/dev/cdrom", O_RDWR)
> cdrom_param_fd = get_param_fd(cdrom_fd) /* a new syscall */
> Now read/write to this param fd.
> And two new entries in the struct file_operations:
> write_param([same args as write])
> read_param([same args as read])

That assumes that there is any sort of uniform semantics for these
operations.  There isn't.  Moreover, you are insisting on pushing
all of them into the same channel; not a good idea since the set
of things done with ioctls tends to consist of several unrelated
classes, often coming from a bunch of unrelated subsystems.

There is no mechanical replacement for ioctl(); the nature of its
problems is that we have a random mix of unrelated operations bumped
into one pile.

Take a look at e.g. networking ioctls.  Most of them openly ignores the
descriptor used to issue an ioctl - more often then not the first thing
they do is to peek into the passed data structure and go looking for
the real object we are going to operate upon; e.g. find an interface by
name.  Of course it's bogus; any sane modification of that API would
have the object selected by the opened file we are passing to it.

And no, we have no chance in hell to rewrite all userland code that
uses these suckers, so we are stuck with them for all forseeable future.
UCB folks had no taste, film at 11...

For more or less common (read: implemented by more than a couple of drivers)
ioctls we have to keep them anyway; for the stuff where we really stand
a chance of doing some kind of changes (including the new operations) we
can bloody well do splitup by files that would match the nature of operations.
Which leaves the "get me secondary channel by fd" kind of operations
without any uses.

  reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-28  0:22 Ozan Eren Bilgen
2004-11-28  0:39 ` Al Viro
2004-11-28  9:59   ` Miklos Szeredi
2004-11-28 10:08     ` Jan Engelhardt
2004-11-28 10:18       ` Miklos Szeredi
2004-11-28 10:28     ` Bernd Eckenfels
2004-11-28 10:56       ` Wichert Akkerman
2004-11-28 11:52         ` Bernd Eckenfels
2004-11-28 11:22       ` Miklos Szeredi
2004-11-28 12:18         ` Al Viro
2004-11-28 12:32           ` Miklos Szeredi
2004-11-28 12:48             ` Al Viro
2004-11-28 12:52               ` Miklos Szeredi
2004-11-28 13:03                 ` Al Viro
2004-11-28 14:30                   ` Tomas Carnecky
2004-11-28 15:27                     ` Al Viro
2004-11-28 18:23                       ` Tomas Carnecky
2004-11-28 18:51                         ` Miklos Szeredi
2004-12-10  4:01                   ` Ingo Oeser
2004-11-28 13:20                 ` Tomas Carnecky
2004-11-28 14:05                   ` Al Viro [this message]
2004-11-28 13:07           ` Tomas Carnecky
2004-11-28 13:11             ` Al Viro
2004-11-28 13:19               ` Tomas Carnecky
2004-11-28 17:42           ` Alan Cox
2004-11-30 13:26           ` Pavel Machek
2004-11-30 15:46             ` Al Viro
2004-11-28 12:23         ` Bernd Eckenfels

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=20041128140552.GD26051@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=ecki-news2004-05@lina.inka.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=tom@dbservice.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git