On Tue, 22 May 2007, Dmitry Torokhov wrote: > On 5/22/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > > I can work with that, yes. In fact I have nothing against it, but current > > rfkill does not allow for the above. > > RFKill sure does not. Rfkill does not support buttons, sliders, knobs > or anything else. That is what input layer for. Userspace is supposed It was beaten into my heads that rfkill has two parts and that one is not to try to use one without the other: The sysfs class, and the input layer stuff. > Alernatively rfkill-input will do smple on/off toggling on switches > that userspace did not claim. And I was TOLD I cannot even look at rfkill sysfs support without taking rfkill-input into the picture. Which is a dubious design decision IMHO, but I am quite willing to go with it. > > > How about polling twice a second? That should cause no appreciable load > > > increase and give userspace a chance to do something clever. > > > > How about polling twice a second, PLUS a notification from rfkill every time > > something wants to read an attribute, so that we nearly close the window of > > opportunity where the status is incorrect? That's what I am asking of > > rfkill, but they are very reluctant to implement. > > Notification to where? The driver? Userspace? Does delay in status > reading of ~0.5 sec matter? You are concerned with the load on the EC To the driver, and yes it matters. > caused by constant polling but are you OK with apllications readig > sysfs attributes constantly (rfkill attributs are exported 0644 or > 0444 so anyone could read them)? Do you want the driver to do No, I am not. And I am so going to rate-limit the entire thinkpad-acpi sysfs interface eventually, you can count on it. And rfkill isn't the reason it will be done, either. Userspace braindamage is. The lack of rate-limiting is a glaring design bug in the entire Linux sysfs interface, as implemented by most drivers (and currently thinkpad-acpi is just as buggy as the rest of them). This is nothing new. > throttling? Do you want rfkill to implement throttling? Driver > specific? I am not asking for it, nor have I ever asked for it. I can do it in the driver, and I expect to have to do it in the driver. It is probably best done in the driver anyway. > All in all it is alot of pain for no reeal gain. Correctness is *always* a gain when it is cheap to implement, and in this case it IS cheap. I only asked for TWO things so far, make no mistake about it: 1. a get_radio_state() hook, that gets called when rfkill needs the state. I sent a patch implementing it, with 100% backwards compatibility for drivers that don't want to implement get_radio_state(). 2. a set_radio_state() method in the class, to change the radio state without causing a loop through the underlying driver. I understand a patch for this is not needed, but it would take about 10 minutes to write one and QA it, and I will do so if anyone asks for it. I didn't ask for rate limiting or anything else. I fully expected I'd have to do it in the driver since I took a first look on rfkill. Just like I will have to eventually rate-limit everything sysfs that causes expensive hardware access. -- "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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
