[OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others... (resending)

[Lucas Ramage]

Excellent idea!

But perhaps we could use either CONFIG_CONSTRAINED, or CONFIG_DEVICE_THIN instead?

Regards,

On May 2, 2020 9:54:16 PM UTC, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
>Hi all,
>
>We sometimes get into debates about whether certain functionality
>should be allowed and oftentimes the gating factor is “will this fit in
>a skinny platform” (i.e. something highly constrained, like 32MB of
>DRAM)?  I suppose there’s a similar argument about what a “small
>footprint” machine has in terms of Flash, as well.
>
>Some of us work with more current machines that are also more capable,
>realizing that eventually machines with 32MB of DRAM and 128MB of Flash
>will “age out” through failure and scarcity.
>
>By then we’ll have a new “normal” about what the minimum expectations
>are, and the conversation will continue, but with different parameters.
>
>Understanding that the definition of a “skinny” machine isn’t today
>what it was 5 years ago, and that it won’t be the same again in another
>5 years, I’d like to proposal a CONFIG_ symbol that denotes that a
>platform is in a class of constrained architectures.
>
>Or, conversely, that a platform doesn’t have to observe overly
>restrictive constraints on “what will fit”.
>
>(The smallest router platform I own has 256MB of DRAM, an 2GB of Flash
>for instance, and it’s a 12 years old PC Engines Alix 2D… most of the
>“current” machines I have are AMD64 and have 64GB of DRAM and 32GB or
>more of Flash… with 256GB being the median…)
>
>This would allow us to develop packaging that both fits into
>constrained architectures, as well as targeting further along the
>evolving curve of “more RAM, more disk” that newer and newer platforms
>inevitably follow.
>
>For instance, I was on IRC yesterday with Jo-Philipp talking about
>whether the xt_geoip database should be propagated across sysupgrades,
>understanding that:
>
>(1) some people might use it in their firewall rules
>(/etc/firewall.user) to block certain country codes as part of their
>system coming up, and don’t want to be in the vulnerable position of
>just having performed a sysupgrade and reboot, but now finding
>themselves without the geo-location database and therefore not able to
>block certain countries, ISPs, etc. that are known to harbor APT’s;
>
>(2) the database takes slightly over 7MB today, and that might be more
>than one can reasonable propagate during a sysupgrade, and some people
>might not want to risk a failed sysupgrade… understanding that they can
>re-download and re-install the database without too much trouble (it
>takes a couple of minutes to download and unpack, even on a modest
>broadband connection);
>
>My proposal is the CONFIG_SKINNY parameter (and possibly others, if we
>need to triage in multiple dimensions; see below).  If this is set,
>then conservative decisions need to be made in packaging about disk and
>RAM consumption.  If this isn’t set, packaging might assume there’s
>“room to stretch one’s legs”.
>
>In the prior scenario, the assumption would be that backing up the
>geo-location database is feasible on unconstrained platforms, and one
>could add:
>
>ifneq ($(CONFIG_SKINNY),y)
>define Package/iptgeoip/conffiles
>/usr/share/xt_geoip/
>endef
>endif
>
>to feeds/packages/net/xtables-addons/Makefile for example.
>
>Then we can move away from the argument about “should X be allowed” to
>the more productive discussion “when is it acceptable to allow X”
>instead?
>
>And hopefully, what’s “allowed” (or viable) will only increase over
>time, giving us more and more options to tailor OpenWRT into the
>optimal configuration for our needs.
>
>So, I put to you 4 questions:
>
>(1) should we include CONFIG_SKINNY?
>(2) what is the minimum DRAM that a platform should have to not be
>considered “skinny”?
>(3) what is the minimum Flash (or other storage) that a platform should
>have to not be considered “skinny”?
>(4) should clock speed figure into this?  or some “normalized”
>accounting of clock speed, that takes super-scalar and deep pipelining
>into consideration, such as MIPS, be considered?  or should this be an
>orthogonal parameter, such as CONFIG_SLOW?
>
>I’ll kick off with my own initial empirically derived answers, with:
>
>(1) yes, it can’t really do any harm… people who don’t want to deal
>with it won’t, making everything effectively “skinny” which is the
>status quo;
>(2) 256MB is already fairly capable… we can use that as the initial
>definition of “skinny” and tweak it as experience dictates is
>reasonable;
>(3) 512MB is also a fair amount of space for image plus extended
>logging;
>(4) above 1000 MIPS, I’d not consider an embedded platform to be
>“slow”… a 500MHz processor executing 2 instructions per cycle, or
>having 2 cores and 1 instruction per core per cycle, is fairly capable,
>easily able to handle traffic shaping on a 100Mb/s link;
>
>What does everyone else think?
>
>Thanks,
>
>-Philip
>
>
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel at lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel