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 15:27:56 +0000
Message-ID: <20041128152756.GL26051@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <41A9E0FB.8030001@dbservice.com>

On Sun, Nov 28, 2004 at 03:30:19PM +0100, Tomas Carnecky wrote:
> You mean.. like nvidia?
> /dev/nvidiactl
> /dev/nvidia0
> /dev/nvidia1
> /dev/nvidia2
> and do read/write on /dev/nvidiactl (instead on ioctl)?

Really depends on situation - in some cases that's the obvious clean
variant, in some you might want something more specific.  Usually
it helps to ask "what object am I working with?" and see if it gives
a reasonable picture.  Note, BTW, that your example (eject) actually
demonstrates what kind of ugliness can be created by piling everything
together - the logics around "it's currently used, do not eject and
return -EBUSY" is broken and unfixable in all cdrom drivers.  Broken
exactly because we need to open device itself to issue eject request.
Think what happens if we get
	fd = open("/dev/cdrom", 0);
	if (fork()) {
		read a lot from that sucker
	} else {
		sleep for a while
		ioctl(fd, CDROMEJECT, 0);
	}
>From the driver point of view, we have only one opener.  There's no way
to tell how many processes might have file descriptors that point to
what we'd opened back then.  So we either need to keep track of all
changes in descriptor tables and provide exclusion between that and
ioctls (have fun) or admit that driver might be hit with eject in the
middle of IO, all logics along the lines of "it's opened by somebody,
no eject for us" nonwithstanding.

And then there are horrors like cciss special-casing the open of 1st disk
on a controller (even if there's none) so that we could talk to controller
itself (in particular, tell it to go look for disks that might be attached
to it now).  It gets very ugly; same for RAID array creation, same for
loop device setup and races around it, etc.

  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 [this message]
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
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=20041128152756.GL26051@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