On 2017-05-07 16:48, kallisti5 wrote:
On 2017-05-07 14:30, Axel Dörfler wrote:
Am 07/05/2017 um 21:16 schrieb Dániel Kasza:
Maintaining custom patches for wpa_supplicant can be really tricky.
There is a lot of obscure functionality there and it is very
difficult to validate the whole thing. My recommendation would be to
keep the OS specific changes to a minimum and upstream them.
Everything else should go in another service that controls
wpa_supplicant through the socket interface.
Or via BMessages, but either way would do.
Yes, that was the original plan -- the net_server should have been the
"remote control" of the wpa_supplicant.
kallisti5 Sent: Sunday, May 7, 2017 2:02 PM To:
2) Upstream our changes? (maybe minus the dialogs and stuff?)
I'm assuming we already tried this?
We had a good run with 1), but we shouldn't overdo it :-)
I think our only valid option is 2), with the added implications of:
a) Port them to current
b) Make the Haiku port as small as possible, and have a remote control
service for it. IIRC other ports already do such a thing.
I don't remember whether or not mmlr tested the water about
upstreaming our patches. It wouldn't hurt to know if they accepted it
as is (ported to current, of course), but the ultimate goal should be
do make the wpa_supplicant a bit more independent, and to remove any
UI from it.
Ok. To get started, maybe I can reduce the size of our patch. (get the
simple #ifdef __HAIKU__ checks upstream)
