Thread (96 messages) 96 messages, 6 authors, 2009-06-11

Re: [PATCH] rfkill: create useful userspace interface

From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Date: 2009-06-01 15:36:22

On Mon, 01 Jun 2009, Johannes Berg wrote:
On Mon, 2009-06-01 at 10:33 -0300, Henrique de Moraes Holschuh wrote:
quoted
I don't know if I have any gripes with your latest patch ;)  Can't test it
right now.  I was reacting to the comments in the thread.
Well could you read it and see if the API does what you require? A
discussion about that would be so much more useful than handwaving about
LED blinking and security issues...
LEDs?  I mean the device being rfkilled/unrfkilled (which often means the
entire device is kicked off the USB bus and hotplugged back)... I must cut
down on comparisons and analogies.

I will look at your patch as soon as I can, I just can't do it right now.
quoted
On a related note, Johannes, would you be opposed to exporting something I
could call from thinkpad-acpi to request a radio state change on a rfkill
struct?   This would allow me to remove some of the mess in thinkpad-acpi.
I don't think I understand what you want? What do you mean by "request a
radio state change"?
As in "please try to block this _specific_ radio", and "please try to
unblock this _specific_ radio".

I.e. what one would do by a write to the "state" attribute of the _old_
rfkill sysfs (and which would get overriden the next time someone changed
the global state, etc).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help