On Thu, May 05, 2016 at 06:41:19PM -0400, David Benjamin wrote: > So, previously, our approach was not to try to support old versions of > BoringSSL much. It's annoying having our own code (much less yours!) > saddled with #ifdefs for our past mistakes. (You all have enough of a > mess on your hands with multiple versions of OpenSSL. I don't want to > make things worse!) Instead, we only use it in environments with > controlled versions that move forwards, so we can coordinate caller > and callee updates, sometimes even atomically. If atomic changes > aren't possible, we'd add very temporary scaffolding #defines and > #ifdefs locally, get to the end state (caller and callee both assumed > new enough) as fast as possible, and dismantle it. In theory, that would be nice in case all components using BoringSSL are only used in the same controlled environment.. > Though talking with Dmitry some more, it sounds like it's actually > desirable to be able to build newer wpa_supplicant against a release > or two behind of AOSP? Is that right? This isn't how we had previous > done things on the BoringSSL end, but we can certainly accommodate it. Yes, my goal is to be able to take a master branch snapshot from hostap.git and be able to build wpa_supplicant from that with at least the latest releases AOSP version or ideally two if the previous one is still being used in significant new development. Quite a bit of Wi-Fi related work happens with and on Android versions that are a bit older than what is in the latest development trees (especially if those trees are not always publicly available). If this can be maintained with couple of well placed #ifdefs, then so be it. I'm willing to take that temporary extra complexity to get the benefits of having a new version that can be built on top of Android versions that are used as the baseline for ongoing development and product releases. > I can start a BORINGSSL_API_VERSION counter and roll that into AOSP > now. This will be a random meaningless number except we promise it > will only increase and we'll probably increment it at points vaguely > corresponding with additions or changes in the API, wherever it ends > up convenient to do so. :-) Then this patch will be updated to be > defined(BORINGSSL_API_VERSION). In future we'd do > BORINGSSL_API_VERSION > whatever. And then you all can figure out how > far back it should go. (For my part, I want to minimize your burden, > so I would encourage you need to retain support for versions older > than you need, but it sounds like your master branch cares about more > Android releases than I thought.) > > Does that sound reasonable? Yes, this would work fine for me and the updated patch you sent looked good as well. And as a side note, most of my automated testing is on non-Android platforms with Linux, so it is a significant benefit to be able to build the latest wpa_supplicant with number of snapshots of BoringSSL on x86_64 Linux. This allows both the current master branch of BoringSSL (i.e., what to expect to see in the products in the future) and various releases version (e.g., based on Android release tags) being used to run through the mac80211_hwsim test runs for regression testing and to come up with new test cases to verify issues that may show up in this area. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
