[RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices

[Adrian Schmutzler]

> I agree, that some of the "small_flash" defaults are probably not the optimal
> choice for 8MB-flash devices.
> A new subtarget might be an option, but is it really worth to define a new
> one for "deprecated" boards? Esp. as it's to be expected that both will vanish
> in the release following 20.xx. A new subtarget feels to me like just adding
> additional maintenance and additional confusion to the users.

IMO it's simply like this:

"Do we want to specifically put efforts into providing a better _default_ experience for this subgroup of devices for a limited time."
YES: Do it properly (which IMO means having a low-mem target for low-mem devices)
NO: Leave the stuff as it is right now.

I personally lean towards "No.". If people still want to use these devices, they are the ones who know best where they can disable stuff and where they can't. This is all perfectly possible with the current implementation as it is right now.

As you state yourself, the devices still work well with standard OpenWrt. The problems arise when you add additional features to them. So, it seems logical to me that you address the results of these additional features at the place where you introduce them, as you will actually know the precise nature of the use case (while we can just provide a framework for a myriad of possible scenarios).

> 
> Adrian, as you mentioned there is currently only one board build for ath79-
> tiny at all. So it's a target that might not be interesting for the average user at
> all. For this it might be a good idea to stop now building this target anyway in
> favor of using the build ressouces more effectively. Getting more images for
> the tiny-subtarget will only change when customizing the config .
> 
> By writing this I wonder if it gives sense to add a new subtarget "deprecated"
> (to all relevant targets) to include all boards that might fall out of support
> "soon" as of limited ressources? This will be a clear statement to the users
> and even easy to determ, when a board belonge to this subtarget. As we
> currently see "tiny" was introduced for the 4/32MB boards but in the
> meanwhile should include the 8/32MB boards, too. In the "next wave" I
> assume 8/64MB boards will belong to this category in some years. Very likely
> the 4/32 and
> 8/32 boards have become unsupportable then anyway and removed from
> the code- basis.

That's the task of documentation, not of code. Again, we have to distinguish between default builds (buildbots) and support itself.
If a device can't be built anymore by buildbots (or is really broken otherwise), it gets disabled via "DEFAULT := n". Any other action of rearrangement would just increase the chance of breaking it with no reason. A deprecated target would even more increase the necessity to maintain config etc. for devices nobody uses anymore. In contrast, with the current setup we essentially still maintain the 8/32 accidentally as we maintain the rest and they benefit from it. I do see no reason to change that.

> 
> 
> I also ran a quick check on the usage of the "small_flash" and "low_mem" flag
> features. They are defined for some targets and used to set the
> "SMALL_FLASH"
> and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no
> other use of them, or did I miss something? If I'm right, the most difference
> between generic and tiny is the "config-default" file.
> When there is no further use of the features, it's nor probably an option to
> think of combining both into something like "low_ressources". Based on this
> some default config-choices can be changed, like "optimize for size",
> disabling some "comfort features". As said before, a smaller binary / kernel
> will save flash-space and RAM-space, even the flash-space might not be
> relevant for all "low_ressources" boards.

Yes, but what falls into which category is always a matter of judgement. Otherwise, we would just enable small_flash and low_mem for all devices ...

Best

Adrian

> 
> Sven
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20201206/c2532207/attachment.sig>