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

[Abuse Department]

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