From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ew0-f176.google.com ([209.85.219.176]:34440 "EHLO mail-ew0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752253AbZFAQJ4 (ORCPT ); Mon, 1 Jun 2009 12:09:56 -0400 Received: by ewy24 with SMTP id 24so7944429ewy.37 for ; Mon, 01 Jun 2009 09:09:57 -0700 (PDT) Message-ID: <4A23FD91.8020200@tuffmail.co.uk> Date: Mon, 01 Jun 2009 17:10:57 +0100 From: Alan Jenkins MIME-Version: 1.0 To: Marcel Holtmann CC: Johannes Berg , John Linville , linux-wireless Subject: Re: [PATCH] rfkill: create useful userspace interface References: <1243524688.10632.0.camel@johannes.local> <9b2b86520905310213n7be56260lc0c2cf3c109fe065@mail.gmail.com> <1243763887.19302.29.camel@johannes.local> <1243796509.6570.35.camel@localhost.localdomain> <1243841639.5299.8.camel@johannes.local> <4A238EA2.4040106@tuffmail.co.uk> <1243858256.5299.14.camel@johannes.local> <1243867620.3015.17.camel@localhost.localdomain> In-Reply-To: <1243867620.3015.17.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-wireless-owner@vger.kernel.org List-ID: Marcel Holtmann wrote: > Hi Johannes, > > >> Would everybody be happy with this rolled in? >> >> johannes >> >> Subject: rfkill: userspace API improvements >> >> This adds the two following things to /dev/rfkill: >> 1) notification to userspace with a new operation >> RFKILL_OP_NVS_REPORT about default states restored >> from platform non-volatile storage >> > > I really don't understand why this is needed. What benefit does it give > us compared to just sent OP_CHANGE and OP_CHANGE as an update. My X200 > for example does this anyway on suspend/resume. > This is required for boot only. I have no reason for this event to be generated on resume. The same effect could be had by generating an OP_CHANGE on f_open, _only_ when a platform driver has provided a value from NVS. But it does seem clearer to make it a different type of event. > So what is rfkilld suppose to be doing when receiving this report? What > is the expected behavior? Why do we bother with multi-OS crap here? I am > really unclear what are we trying to solve here. > In order to replicate the kernel behavior, it is expected that you set your internal state from this event. E.g. when the user next presses the wireless toggle key, you set the inverse of that internal state. Since this event is generated by a platform driver, you can expect it to be present following coldplug (the udev initscript). If the event is not present after coldplug, you may then issue OP_CHANGE yourself, to e.g. restore the state from a file. You would not be expected to handle OP_NVS_REPORT after startup. (Unless the daemon is restarted). Replicating the kernel behavior will allow us to avoid causing a couple of niggly little regressions on at least two platforms. It preserves the behavior when dual-booting (possibly between different linux distros), and when the BIOS setup screen exposes the NVS state as an option. The new behavior you suggest will annoy any users who have become used to these scenarios "just working". You may not use these platforms yourself. But I'm as annoyed as Henrique is, we don't want to impose regressions just because other platforms don't implement the feature. Why the fuss about implementing this, it seems easy enough? Start rfkilld after udev (like everything else). If you get NVS_REPORT, then use those states. Fill in any other states from defaults or state files and issue OP_CHANGE for them, just as you're already planning. Ignore any subsequent NVS_REPORTs. That should cover it. It's the cost for starting from a working implementation. You benefit from having existing drivers and users, you pay by not breaking them without good reason. Thanks Alan