[full quoting for linux-{kernel,wireless} & the perpetrator]
I demand that Thiemo Nagel may or may not have written...
> Corentin Chary wrote:
>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<[email protected]>
>> wrote:
>>> Corentin Chary wrote:
>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
>>>> Nagel<[email protected]> wrote:
>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
>>>>> on my EeePC 1000HGO:
>>>>> eee:/# cat /sys/class/rfkill/rfkill2/name
>>>>> eeepc-wwan3g
>>>>> eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
>>>>> bash: echo: write error: Operation not permitted
>>>>> What could be the reason for that?
>>>> Reading the kernel source I can find:
>>>> /*
>>>> * The intention was that userspace can only take control over
>>>> * a given device when/if rfkill-input doesn't control it due
>>>> * to user_claim. Since user_claim is currently unsupported,
>>>> * we never support changing the state from userspace -- this
>>>> * can be implemented again later.
>>>> */
>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
>>>> Documentation/rfkill.txt).
>>>> Maybe network-manager can control that .. But I'm not sure.
>>>> Maybe you should CC the wireless mailing list.
>>> Thanks for the quick reply. The interesting thing is, that the direct
>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills. I've CC'd
>>> debian-eeepc-devel, maybe they know something.
>> Are you sure that it works with newer kernels ?
>> This commit should have broken it for all rfkill.
>> commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
>> Author: Johannes Berg <[email protected]>
>> Date: Tue Jun 2 13:01:37 2009 +0200
> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.
This is the first that I've heard of this. I'd not noticed since I've not
needed Bluetooth on my 901 recently.
> For the debian-eeepc folks: 2.6.31-rc2 breaks bluetooth toggling using
> eeepc-acpi-scripts, but WLAN toggling still works.
FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
different problem.
I consider this a regression. It breaks an interface which, though flawed, is
ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
scripts.
/dev/rfkill is not useful in shell scripts.
Trying to read from it to determine the current state (and only the current
state) results in the shell effectively hanging, and parsing is less than
trivial. So either we continue to use .../state or eeepc-acpi-scripts needs a
complete rewrite of the ACPI event-handling scripts in something other than
sh (probably perl) and would need a daemon instead of having scripts launched
from acpid (well, that or they'd need a helper binary or two).
Writing to it is doable, though slightly interesting. "echo 1 >/..." is
ideal.
We can't just drop support for older kernels ‒ at least, not yet – though
fortunately, prior to this breakage, all that we had to cope with were
changed file names; the content can be treated identically. We don't have to
deal with hard-blocked states, which helps...
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
Passwords are implemented as a result of insecurity.
On Fri, Jul 10, 2009 at 8:57 PM, Darren
Salt<[email protected]> wrote:
> [full quoting for linux-{kernel,wireless} & the perpetrator]
>
> I demand that Thiemo Nagel may or may not have written...
>
>> Corentin Chary wrote:
>>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<[email protected]>
>>> wrote:
>>>> Corentin Chary wrote:
>>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
>>>>> Nagel<[email protected]> wrote:
>>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
>>>>>> on my EeePC 1000HGO:
>>>>>> ? eee:/# cat /sys/class/rfkill/rfkill2/name
>>>>>> ? eeepc-wwan3g
>>>>>> ? eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
>>>>>> ? bash: echo: write error: Operation not permitted
>>>>>> What could be the reason for that?
>>>>> Reading the kernel source I can find:
>>>>> ? ? ? ? /*
>>>>> ? ? ? ? ?* The intention was that userspace can only take control over
>>>>> ? ? ? ? ?* a given device when/if rfkill-input doesn't control it due
>>>>> ? ? ? ? ?* to user_claim. Since user_claim is currently unsupported,
>>>>> ? ? ? ? ?* we never support changing the state from userspace -- this
>>>>> ? ? ? ? ?* can be implemented again later.
>>>>> ? ? ? ? ?*/
>>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
>>>>> Documentation/rfkill.txt).
>>>>> Maybe network-manager can control that .. But I'm not sure.
>>>>> Maybe you should CC the wireless mailing list.
>>>> Thanks for the quick reply. ?The interesting thing is, that the direct
>>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills. ?I've CC'd
>>>> debian-eeepc-devel, maybe they know something.
>>> Are you sure that it works with newer kernels ?
>>> This commit should have broken it for all rfkill.
>>> ? commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
>>> ? Author: Johannes Berg <[email protected]>
>>> ? Date: ? Tue Jun 2 13:01:37 2009 +0200
>
>> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.
>
> This is the first that I've heard of this. I'd not noticed since I've not
> needed Bluetooth on my 901 recently.
>
>> For the debian-eeepc folks: ?2.6.31-rc2 breaks bluetooth toggling using
>> eeepc-acpi-scripts, but WLAN toggling still works.
>
> FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
> different problem.
>
> I consider this a regression. It breaks an interface which, though flawed, is
> ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
> scripts.
>
> /dev/rfkill is not useful in shell scripts.
Maybe it would be possible with an rfkill command line tool (in C) ?
Is there such a tool somewhere ?
--
Corentin Chary
http://xf.iksaif.net - http://uffs.org
Hi Corentin,
> > I demand that Thiemo Nagel may or may not have written...
> >
> >> Corentin Chary wrote:
> >>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<[email protected]>
> >>> wrote:
> >>>> Corentin Chary wrote:
> >>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
> >>>>> Nagel<[email protected]> wrote:
> >>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
> >>>>>> on my EeePC 1000HGO:
> >>>>>> eee:/# cat /sys/class/rfkill/rfkill2/name
> >>>>>> eeepc-wwan3g
> >>>>>> eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
> >>>>>> bash: echo: write error: Operation not permitted
> >>>>>> What could be the reason for that?
> >>>>> Reading the kernel source I can find:
> >>>>> /*
> >>>>> * The intention was that userspace can only take control over
> >>>>> * a given device when/if rfkill-input doesn't control it due
> >>>>> * to user_claim. Since user_claim is currently unsupported,
> >>>>> * we never support changing the state from userspace -- this
> >>>>> * can be implemented again later.
> >>>>> */
> >>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
> >>>>> Documentation/rfkill.txt).
> >>>>> Maybe network-manager can control that .. But I'm not sure.
> >>>>> Maybe you should CC the wireless mailing list.
> >>>> Thanks for the quick reply. The interesting thing is, that the direct
> >>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills. I've CC'd
> >>>> debian-eeepc-devel, maybe they know something.
> >>> Are you sure that it works with newer kernels ?
> >>> This commit should have broken it for all rfkill.
> >>> commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
> >>> Author: Johannes Berg <[email protected]>
> >>> Date: Tue Jun 2 13:01:37 2009 +0200
> >
> >> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.
> >
> > This is the first that I've heard of this. I'd not noticed since I've not
> > needed Bluetooth on my 901 recently.
> >
> >> For the debian-eeepc folks: 2.6.31-rc2 breaks bluetooth toggling using
> >> eeepc-acpi-scripts, but WLAN toggling still works.
> >
> > FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
> > different problem.
> >
> > I consider this a regression. It breaks an interface which, though flawed, is
> > ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
> > scripts.
> >
> > /dev/rfkill is not useful in shell scripts.
>
> Maybe it would be possible with an rfkill command line tool (in C) ?
> Is there such a tool somewhere ?
yes there is:
http://git.sipsolutions.net/?p=rfkill.git
Regards
Marcel
Apparently there actually _are_ tools that try to set
this in sysfs even though it wasn't supposed to be used
this way without claiming first. Guess what: now that
I've cleaned it all up it doesn't matter and we can
simply allow setting the soft-block state in sysfs.
Signed-off-by: Johannes Berg <[email protected]>
---
*shrug*, I don't like it, but whatever...
Please test & report.
net/rfkill/core.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
--- wireless-testing.orig/net/rfkill/core.c 2009-07-10 21:29:10.000000000 +0200
+++ wireless-testing/net/rfkill/core.c 2009-07-10 21:36:31.000000000 +0200
@@ -648,15 +648,26 @@ static ssize_t rfkill_state_store(struct
struct device_attribute *attr,
const char *buf, size_t count)
{
- /*
- * The intention was that userspace can only take control over
- * a given device when/if rfkill-input doesn't control it due
- * to user_claim. Since user_claim is currently unsupported,
- * we never support changing the state from userspace -- this
- * can be implemented again later.
- */
+ struct rfkill *rfkill = to_rfkill(dev);
+ unsigned long state;
+ int err;
+
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
+ err = strict_strtoul(buf, 0, &state);
+ if (err)
+ return err;
+
+ if (state != RFKILL_USER_STATE_SOFT_BLOCKED &&
+ state != RFKILL_USER_STATE_UNBLOCKED)
+ return -EINVAL;
+
+ mutex_lock(&rfkill_global_mutex);
+ rfkill_set_block(rfkill, state == RFKILL_USER_STATE_SOFT_BLOCKED);
+ mutex_unlock(&rfkill_global_mutex);
- return -EPERM;
+ return err ?: count;
}
static ssize_t rfkill_claim_show(struct device *dev,
I demand that Johannes Berg may or may not have written...
> Apparently there actually _are_ tools that try to set this in sysfs even
> though it wasn't supposed to be used this way without claiming first.
Then it should have been documented as such. I don't see anything about this
in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
statement that "Kernel handles events", which isn't exactly helpful :-\
> Guess what: now that I've cleaned it all up it doesn't matter and we can
> simply allow setting the soft-block state in sysfs.
:-)
> Signed-off-by: Johannes Berg <[email protected]>
> ---
> *shrug*, I don't like it, but whatever...
I do. It means that we have a nice simple text-based interface for use in
scripts (for now), and a binary interface which is better suited to the likes
of desktop applications.
> Please test & report.
With the patch applied, Bluetooth toggling is working again, so you get to
add this:
Tested-By: Darren Salt <[email protected]>
[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING.
For sale: one complete set of hen's teeth.
On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> I demand that Johannes Berg may or may not have written...
>
> > Apparently there actually _are_ tools that try to set this in sysfs even
> > though it wasn't supposed to be used this way without claiming first.
>
> Then it should have been documented as such. I don't see anything about this
> in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> statement that "Kernel handles events", which isn't exactly helpful :-\
Oh, it's not just that rfkill was horrible, the documentation matched :)
All the SHOUTING in it about what you must and must not do but nothing
actually helpful :)
> > *shrug*, I don't like it, but whatever...
>
> I do. It means that we have a nice simple text-based interface for use in
> scripts (for now), and a binary interface which is better suited to the likes
> of desktop applications.
Indeed, and as long as you expect to only use soft toggle... problem is
that you won't know whether it's soft-toggled or not while it's
hard-blocked (off)!
> > Please test & report.
>
> With the patch applied, Bluetooth toggling is working again, so you get to
> add this:
>
> Tested-By: Darren Salt <[email protected]>
Ok, John, please pick up the patch.
johannes
I demand that Johannes Berg may or may not have written...
> On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
>> I demand that Johannes Berg may or may not have written...
[snip]
>>> *shrug*, I don't like it, but whatever...
>> I do. It means that we have a nice simple text-based interface for use in
>> scripts (for now), and a binary interface which is better suited to the
>> likes of desktop applications.
> Indeed, and as long as you expect to only use soft toggle... problem is
> that you won't know whether it's soft-toggled or not while it's
> hard-blocked (off)!
Which is fine for eeepc-acpi-scripts and anything else which doesn't care
about hard-blocking because the hardware doesn't do that.
eeepc-acpi-scripts should eventually use your rfkill utility, though. (I
intend to make sure that it does so.)
[snip]
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| Kill all extremists!
A large dog will have a surprising effect on your life.
On Friday 10 July 2009, Johannes Berg wrote:
> On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > I demand that Johannes Berg may or may not have written...
> >
> > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > though it wasn't supposed to be used this way without claiming first.
> >
> > Then it should have been documented as such. I don't see anything about this
> > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > statement that "Kernel handles events", which isn't exactly helpful :-\
>
> Oh, it's not just that rfkill was horrible, the documentation matched :)
> All the SHOUTING in it about what you must and must not do but nothing
> actually helpful :)
>
> > > *shrug*, I don't like it, but whatever...
> >
> > I do. It means that we have a nice simple text-based interface for use in
> > scripts (for now), and a binary interface which is better suited to the likes
> > of desktop applications.
>
> Indeed, and as long as you expect to only use soft toggle... problem is
> that you won't know whether it's soft-toggled or not while it's
> hard-blocked (off)!
>
> > > Please test & report.
> >
> > With the patch applied, Bluetooth toggling is working again, so you get to
> > add this:
> >
> > Tested-By: Darren Salt <[email protected]>
>
> Ok, John, please pick up the patch.
Is there anything going on with the patch?
Surely it's not in -rc4.
Rafael
On Sat, Jul 25, 2009 at 10:56:43PM +0200, Rafael J. Wysocki wrote:
> On Friday 10 July 2009, Johannes Berg wrote:
> > On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > > I demand that Johannes Berg may or may not have written...
> > >
> > > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > > though it wasn't supposed to be used this way without claiming first.
> > >
> > > Then it should have been documented as such. I don't see anything about this
> > > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > > statement that "Kernel handles events", which isn't exactly helpful :-\
> >
> > Oh, it's not just that rfkill was horrible, the documentation matched :)
> > All the SHOUTING in it about what you must and must not do but nothing
> > actually helpful :)
> >
> > > > *shrug*, I don't like it, but whatever...
> > >
> > > I do. It means that we have a nice simple text-based interface for use in
> > > scripts (for now), and a binary interface which is better suited to the likes
> > > of desktop applications.
> >
> > Indeed, and as long as you expect to only use soft toggle... problem is
> > that you won't know whether it's soft-toggled or not while it's
> > hard-blocked (off)!
> >
> > > > Please test & report.
> > >
> > > With the patch applied, Bluetooth toggling is working again, so you get to
> > > add this:
> > >
> > > Tested-By: Darren Salt <[email protected]>
> >
> > Ok, John, please pick up the patch.
>
> Is there anything going on with the patch?
>
> Surely it's not in -rc4.
commit f54c142725ad2ba33c3ee627873cb6966bf05447
Author: Johannes Berg <[email protected]>
Date: Fri Jul 10 21:41:39 2009 +0200
rfkill: allow toggling soft state in sysfs again
Apparently there actually _are_ tools that try to set
this in sysfs even though it wasn't supposed to be used
this way without claiming first. Guess what: now that
I've cleaned it all up it doesn't matter and we can
simply allow setting the soft-block state in sysfs.
Signed-off-by: Johannes Berg <[email protected]>
Tested-By: Darren Salt <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Didn't make -rc4, should be in -rc5.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
?Viva Honduras Libre!
On Sunday 26 July 2009, John W. Linville wrote:
> On Sat, Jul 25, 2009 at 10:56:43PM +0200, Rafael J. Wysocki wrote:
> > On Friday 10 July 2009, Johannes Berg wrote:
> > > On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > > > I demand that Johannes Berg may or may not have written...
> > > >
> > > > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > > > though it wasn't supposed to be used this way without claiming first.
> > > >
> > > > Then it should have been documented as such. I don't see anything about this
> > > > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > > > statement that "Kernel handles events", which isn't exactly helpful :-\
> > >
> > > Oh, it's not just that rfkill was horrible, the documentation matched :)
> > > All the SHOUTING in it about what you must and must not do but nothing
> > > actually helpful :)
> > >
> > > > > *shrug*, I don't like it, but whatever...
> > > >
> > > > I do. It means that we have a nice simple text-based interface for use in
> > > > scripts (for now), and a binary interface which is better suited to the likes
> > > > of desktop applications.
> > >
> > > Indeed, and as long as you expect to only use soft toggle... problem is
> > > that you won't know whether it's soft-toggled or not while it's
> > > hard-blocked (off)!
> > >
> > > > > Please test & report.
> > > >
> > > > With the patch applied, Bluetooth toggling is working again, so you get to
> > > > add this:
> > > >
> > > > Tested-By: Darren Salt <[email protected]>
> > >
> > > Ok, John, please pick up the patch.
> >
> > Is there anything going on with the patch?
> >
> > Surely it's not in -rc4.
>
> commit f54c142725ad2ba33c3ee627873cb6966bf05447
> Author: Johannes Berg <[email protected]>
> Date: Fri Jul 10 21:41:39 2009 +0200
>
> rfkill: allow toggling soft state in sysfs again
>
> Apparently there actually _are_ tools that try to set
> this in sysfs even though it wasn't supposed to be used
> this way without claiming first. Guess what: now that
> I've cleaned it all up it doesn't matter and we can
> simply allow setting the soft-block state in sysfs.
>
> Signed-off-by: Johannes Berg <[email protected]>
> Tested-By: Darren Salt <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
>
> Didn't make -rc4, should be in -rc5.
Great, thanks!
Best,
Rafael