From: Greg KH <gregkh@linuxfoundation.org>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Colin Cross <ccross@android.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>,
lkml <linux-kernel@vger.kernel.org>,
Bryan Wu <bryan.wu@canonical.com>
Subject: Re: sysfs permissions on dynamic attributes (led delay_on and delay_off)
Date: Sat, 21 Jul 2012 09:15:23 -0700 [thread overview]
Message-ID: <20120721161523.GB22896@kroah.com> (raw)
In-Reply-To: <20120721160855.GB7565@khazad-dum.debian.net>
On Sat, Jul 21, 2012 at 01:08:55PM -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 21 Jul 2012, Colin Cross wrote:
> > The delay_on and delay_off files could easily override the values from
> > the trigger.
> >
> > Sending a KOBJ_CHANGE uevent is not a great solution, it's still
> > horribly racy in userspace. This script would never work reliably:
> > echo timer > trigger
> > echo 1000 > delay_on
> > echo 1000 > delay_off
> > echo 255 > brightness
>
> Yes, and the proper fix is to instead use a fully async userspace based on
> uevent callbacks. Nasty as all hell. Or the quick fix, which is to wait
> for the system to settle after every sysfs operation that could create new
> sysfs nodes.
>
> You could make sure that (1) no sysfs operation will return control to
> userspace until it is complete, so you'd have all new sysfs nodes available
> at the time the first echo returns [I believe it already works like that],
Yes it does, what's the problem here?
> and (2) either enhance sysfs to create nodes with the desired ownership and
> permissions
>From the kernel, you can also do this today, if you know it's "safe" for
users to read/write them.
greg k-h
next prev parent reply other threads:[~2012-07-21 16:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 0:46 sysfs permissions on dynamic attributes (led delay_on and delay_off) Colin Cross
2012-07-21 4:08 ` Greg KH
2012-07-21 5:14 ` Colin Cross
2012-07-21 15:07 ` Greg KH
2012-07-21 7:33 ` Richard Purdie
2012-07-21 8:26 ` Colin Cross
2012-07-21 11:21 ` Richard Purdie
2012-07-21 14:31 ` Henrique de Moraes Holschuh
2012-07-21 15:42 ` Colin Cross
2012-07-21 16:08 ` Henrique de Moraes Holschuh
2012-07-21 16:15 ` Greg KH [this message]
2012-07-21 16:23 ` Colin Cross
2012-07-21 16:13 ` Greg KH
2012-07-21 16:22 ` Colin Cross
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=20120721161523.GB22896@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bryan.wu@canonical.com \
--cc=ccross@android.com \
--cc=hmh@hmh.eng.br \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.purdie@linuxfoundation.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.