Am Sonntag, 20. September 2020, 00:21:44 CEST schrieb Adrian Schmutzler: > > Indeed "LOW_MEMORY_FOOTPRINT" seems only to affedt 3 general options > > and one option of OpenSSL. > > > > So it might be an option to : > > * set LOW_MEM for 8/32 MB devies > > * set LOW_MEM and SMALL_FLASH for 4/32 MB devices > > * check the CONFIG-options for usefull defaults So the tiny aubtarget can > > be defined as "boards with 32MB or less of RAM; some boards also with > > only 4MB of flash". This definition would essentially match the "4/32 > > warning" [1]. > Actually, this narrows down to a question that struck me several times > already: > > Now, that 4 MB flash devices are not "supported" anymore, how should we deal > with the "tiny" subtargets: > > 1. We keep the tiny subtargets configured for low flash, so people still > trying to build 4 MB flash devices still can use this. (This will also > benefit a few devices with kernel size restrictions; however, this is a > much smaller set than in earlier times; most of these devices have > dual-stage bootloaders now or died anyway). > > 2. We convert the tiny targets to low-memory targets; this will improve the > situation for a few devices (like you mentioned), but will make it much > harder to still build the 4M flash devices without major changes. Apart > from ath79, I don't know whether this would make sense for other targets > like the old subtargets on ramips. This poses the risk of having some > targets low-mem and some small-flash, which I'd like to avoid. > Additionally, we will have to change back from low-mem to small-flash again > when we start to hit limits with the 8M devices. > > 3. Though not intended by this conversation, the third option is obviously > to just ignore all 4M or 32M devices from now on (as actually announced by > the 4/32 warning), and design the tiny targets based on the requirements of > the 8M devices that will start to become a "problem" soon (either due to > kernel size restrictions or because of small rootfs). Actually, we already > went into this direction by using wpad-basic-wolfssl on tiny targets as > well. >
Adrian, thanks for reminding that 4/32 have be planned to phase out after 19.07. This will or have to be done in the near future. Reading your points my quick idea was: "Moving the 4/32 and 8/32 to the tiny- target for 20.xx and removing this target after 20.xx bramch-off". This shows clearly for 20.xx what will happen soon and the user can prepare for this finally. The code can possibly also cahnged to take more advantage of "low_mem" and "small_flash" flags for the "next 8/64 round". regarding yout concerns that mixing 4/32 and 8/32 will make some more devices not usable I think like: this will break probably some 4/32 on tiny, but will make some 8/32 more usable. As the 4/32 warning is around fror some years now, nobody should be really surprised that the boards "dying" and that the 4/32 boards dying before the 8/32. Best Sven _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel