-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: |> Yeah I take it to mean when you return from the rfkill action, the |> stopping of RF TX is done already. That sounds doable? | | We could introduce a synchronization point (currently, there's none | for this kind of operation). This would make sure that the command | has at least started by the time we return. I'm not sure if rfkill | actually cares about this, but it seems like a good idea anyway. | |> Well killing TX kills association, kills any connectivity lying around, |> etc. It inherently affects everything on top of the network interface. |> ~ I think maybe we can just do it and the sky won't fall? | | It's things like whether rfkill is allowed to reset the ESSID or | what should happen if you try to change the ESSID while rfkill is | in force. ESSID is just a prominent example. There's plenty more | parameters. | | Anyway, you don't need to convince me that it would be pleasant | if all this was in fact nice and simple ;-)
Well I am sure it is not that trivial to implement. But is the multiweek stall for imagined total perfection on the detail of what it impacts from day 1 ever going to pay anything back? Or would it have been better to just do it and refine it (eg stash / restore essid) if trouble is seen. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklrGD8ACgkQOjLpvpq7dMoUHACeJH8nJqjcp4Yu1DVsErH3Xe+F 3OwAn1+56ukRLcuak9aNmcN9HNJT6iNj =P05f -----END PGP SIGNATURE----- _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
