> On Jul 25, 2020, at 1:36 AM, Stijn Segers <[email protected]> wrote: > > Hi Petr, > > Op zaterdag 25 juli 2020 om 10u08 schreef Petr Štetiar <[email protected]>: >> [email protected] <[email protected]> [2020-07-24 17:36:08]: >> Hi, >>> I would prefer to not touch ar71xx here, as this is essentially only used >>> for backporting, and changing stuff would only make these backports more >>> complicated, while not really providing a benefit. (I'm not sure whether it >>> can be still built with master at all.) >> ok, noted. >>> Despite, is my impression correct that this patchset won't affect the size >>> of pure "tiny" targets, like ath79/tiny? >> Good catch. It was all just done with git grep & sed replacing wpad-basic >> with >> wpad-basic-wolfssl, so this targets were missed as they're using wpad-mini. > > I read Adrian's reply as 'we'll keep ath79/tiny out of the wpad SSL push?' > but I > might be mistaken of course. > >> I'm going to switch those to wpad-basic-wolfssl variant as well, since it >> seems that the only difference is CONFIG_IEEE80211R=n in wpad-mini. > > I think that will kill even more tiny images (master has been seeing a lot of > those > being disabled lately). On my TL-WR841ND v7, e.g., I have stripped some more > stuff > from master, after the 5.4 bump (which was to be expected). I was able to > squeeze > in wpad-basic again for the 802.11r (PPP removed though), but it's not like > those tiny > targets have 20 kB to spare, from what I can tell. > > (I heard through the grapevine older flash/RAM constrained devices might just > stick > with kernel 4.19 btw? ath79/tiny is already on 5.4.) > > Since ath79/tiny is a separate subtarget altogether, it makes sense to offer > them with > fewer features. Unless I'm mistaken we'll see a lot of ramips/mt76{20,x8} > stuff going > the same route in the near future, they have similar flash constraints. I > don't think > feature parity with more recent targets (or ones with more space) is what one > should > aim for, with a separate subtarget. > > > Just my 2 cents. > > Stijn > > P.S. Is there a way to use mbedtTLS with wpad? That would be neat since one > could have > LuCI SSL and wpad lean on the same crypto library. I am now building images > with mbedTLS > for LuCI and wolfssl for wpad; it's still smaller than having both build with > OpenSSL > but a bit cumbersome nonetheless. I will note that WolfSSL is based on OpenSSL, meaning it’s not too difficult to add wolfSSL support to OpenSSL packages. > > >> Adding SAE (as all images should support WPA3-Personal from now on) is adding >> way more to the images, so excluding 802.11r doesn't make sense as the size >> difference would be probably negligible compared to the size of wolfSSL, >> certificates etc. >> -- ynezz >> _______________________________________________ >> openwrt-devel mailing list >> [email protected] >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
