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

Sat May 2 19:26:08 EDT 2020

I like “CONSTRAINED” as well.

We could even have:

CONFIG_CONSTRAINED_MEM

and:

CONFIG_CONSTRAINED_DISK

and if either is set, then it sets CONFIG_CONSTRAINED as well.

> On May 2, 2020, at 4:09 PM, Lucas Ramage <oxr463 at gmx.us> wrote:
> 
> 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

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