From: Bill Gatliff <bgat@billgatliff.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
Date: Tue, 09 Feb 2010 22:18:32 -0600 [thread overview]
Message-ID: <4B723398.70806@billgatliff.com> (raw)
In-Reply-To: <4B723239.4090802@billgatliff.com>
Bill Gatliff wrote:
>>> +
>>> + p->requester = requester;
>>> + if (!strcmp(requester, REQUEST_SYSFS))
>>> + p->pid = current->pid;
>>>
>>>
>> This is new.. What's the reason for saving the pid?
>>
>>
>
> I've gotten complaints from those who say, "Ok, so it reported 'sysfs'
> back to me, but how can I be sure that it's because *I* own it now, and
> not another user process?" Seemed easy enough to add the PID so they
> can check. Of course, you could argue that I could report just the PID,
> and skip the "sysfs" string altogether. I'd be inclined to agree with you.
>
> Of course, if you are like me and do the request with cat(1), then the
> PID is pretty meaningless. :)
>
For the record, this request activity is mostly advisory. I can't
actually implement something where only the requester is subsequently
allowed to manipulate the state of the channel. You really wouldn't
want to even if it was possible, because then you'd probably lose the
ability to control the output using cat(1) and echo(1).
I'm just trying to provide a tool that allows users to Play Nice if they
choose to. In fact, it's currently possible to manipulate the state of
the channel from userspace without requesting ownership first. Not sure
I'm happy with that, but since I can't enforce any sort of access
restrictions it seems pointless to even go so far as to require ownership...
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
next prev parent reply other threads:[~2010-02-10 4:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 20:46 [PWM PATCH 0/7] Generic PWM API Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 2/7] Emulates PWM hardware using a high-resolution timer and a GPIO pin Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 3/7] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 4/7] Implements PWM-based LED control Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 5/7] LED "dim" trigger based on PWM control of the LED Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 6/7] Incorporate PWM API code into KBuild Bill Gatliff
2010-02-09 20:46 ` [PWM PATCH 7/7] PWM API driver for MPC52xx GPT peripheral Bill Gatliff
[not found] ` <8B7FF140-BE6E-4AD1-86BC-161488675DFB@lvk.cs.msu.su>
2010-02-10 13:42 ` [PWM PATCH 2/7] Emulates PWM hardware using a high-resolution timer and a GPIO pin Bill Gatliff
2010-02-10 2:41 ` [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface H Hartley Sweeten
2010-02-10 4:12 ` Bill Gatliff
2010-02-10 4:18 ` Bill Gatliff [this message]
2010-02-10 17:34 ` H Hartley Sweeten
2010-02-10 13:55 ` Bill Gatliff
2010-02-10 18:33 ` H Hartley Sweeten
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=4B723398.70806@billgatliff.com \
--to=bgat@billgatliff.com \
--cc=hartleys@visionengravers.com \
--cc=linux-embedded@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).