public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi@mandriva.org>
To: Andrew Morton <akpm@osdl.org>
Cc: dtor_core@ameritech.net, linux-joystick@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 03/11] input: new force feedback interface
Date: Thu, 25 May 2006 17:45:06 +0300	[thread overview]
Message-ID: <4475C2F2.7090207@mandriva.org> (raw)
In-Reply-To: <20060525070017.16344c97.akpm@osdl.org>

Andrew Morton wrote:
> Anssi Hannula <anssi@mandriva.org> wrote:
> 
>> >>+int input_ff_erase(struct input_dev *dev, int id)
>> >>+{
>> >>+	struct ff_device *ff;
>> >>+	unsigned long flags = 0;
>> >>+	int ret;
>> >>+	if (!test_bit(EV_FF, dev->evbit))
>> >>+		return -EINVAL;
>> >>+	mutex_lock(&dev->ff_lock);
>> >>+	ff = dev->ff;
>> >>+	if (!ff) {
>> >>+		mutex_unlock(&dev->ff_lock);
>> >>+		return -ENODEV;
>> >>+	}
>> >>+	spin_ff_cond_lock(ff, flags);
>> >>+	ret = _input_ff_erase(dev, id, current->pid == 0);
>> >>+	spin_ff_cond_unlock(ff, flags);
>> >>+
>> >>+	mutex_unlock(&dev->ff_lock);
>> >>+	return ret;
>> >>+}
>> > 
>> > 
>> > Perhaps you meant `current->uid == 0' here.  There's no way in which pid
>> > 0 will call this code.
>>
>> Right, a silly mistake.
>>
>> > What's happening here anyway?  Why does this code need to know about pids?
>> > 
>> > Checking for uid==0 woud be a fishy thing to do as well.
>>
>> User ID 0 is allowed to delete effects of other users. Pids are used to
>> keep a track of what process owns what effects. This is the same
>> behaviour as before.
> 
> 
> Oh dear.
> 
> Whatever we do here should remain 100%-compatible with "before".  Which
> rather limits our options.

There are only _very_ few programs using FF on Linux ATM, and I don't
think any of them opens multiple fd:s to the same device and expects to
be able to delete effects created on the other fd. And that is the only
con of changing the behaviour.

Should the behaviour be changed so that the effect owners are file
descriptors, the effects of one fd would not be lost if the process
opens and closes another fd on the same device (currently all effects of
a process are deleted if the process closes any fd to the device).

>> There is a problem with this, though:
>> When a process closes any fd to this device, all pid-matching effects
>> are deleted whether the process has another fd using the device or not.
>>
>> One solution would probably be to add some handle parameter to
>> input_ff_upload() and input_ff_erase(), and then in
>> evdev_ioctl_handler() pass an id unique to this fd. Then effects would
>> be fd-specific, not pid-specific. I think the uid == 0 thing can also be
>> dropped... I don't think the root user needs ability to override user
>> effects (it can delete them anyway, just kill the user process owning
>> the effects).
>>
> 
> 
> Generally we use file descriptors (and driver-specific state at
> file.f_private) to manage things like that.  But I'd imagine that we
> couldn't retain the existing semantics with any such scheme.
> 
> A pragmatic approach would be to put a big fat comment in there explaining
> how it all works and leave it at that.

As I don't see this could break any existing applications, I would very
much like to change the behaviour so that the effects are file
descriptor specific. What should I use to differentiate the descriptors?
Can I just compare the "struct file*"? (it seems to work well, I just
modified the code so)

-- 
Anssi Hannula


  reply	other threads:[~2006-05-25 14:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-15 21:12 [patch 00/11] input: force feedback updates Anssi Hannula
2006-05-15 21:12 ` [patch 01/11] input: move fixp-arith.h to drivers/input Anssi Hannula
2006-05-15 21:12 ` [patch 02/11] input: fix accuracy of fixp-arith.h Anssi Hannula
2006-05-15 21:12 ` [patch 03/11] input: new force feedback interface Anssi Hannula
2006-05-18  5:20   ` Andrew Morton
2006-05-22 16:10     ` Anssi Hannula
2006-05-24 10:45       ` Anssi Hannula
2006-05-25  0:49         ` Andrew Morton
2006-05-26 16:32           ` Anssi Hannula
2006-05-25  9:00     ` Anssi Hannula
2006-05-25 14:00       ` Andrew Morton
2006-05-25 14:45         ` Anssi Hannula [this message]
2006-05-25 14:52           ` Andrew Morton
2006-05-25 16:35             ` Anssi Hannula
2006-05-15 21:12 ` [patch 04/11] input: adapt hid force feedback drivers for the new interface Anssi Hannula
2006-05-15 21:12 ` [patch 05/11] input: adapt uinput for the new force feedback interface Anssi Hannula
2006-05-15 21:12 ` [patch 06/11] input: adapt iforce driver " Anssi Hannula
2006-05-15 21:12 ` [patch 07/11] input: force feedback driver for PID devices Anssi Hannula
2006-05-15 21:12 ` [patch 08/11] input: force feedback driver for Zeroplus devices Anssi Hannula
2006-05-15 21:12 ` [patch 09/11] input: update documentation of force feedback Anssi Hannula
2006-05-15 21:12 ` [patch 10/11] input: drop the remains of the old ff interface Anssi Hannula
2006-05-15 21:12 ` [patch 11/11] input: drop the old PID driver Anssi Hannula
2006-05-17 13:30 ` [patch 00/11] input: force feedback updates Dmitry Torokhov

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=4475C2F2.7090207@mandriva.org \
    --to=anssi@mandriva.org \
    --cc=akpm@osdl.org \
    --cc=dtor_core@ameritech.net \
    --cc=linux-joystick@atrey.karlin.mff.cuni.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox